ES2704660T3 - Procedimiento y dispositivo para la renderización en línea de archivos de juego - Google Patents

Abstract

Un procedimiento para renderizar un archivo de juego (502) que representa un intervalo de juego en vivo de un juego correspondiente para que sea visible sin el juego correspondiente, comprendiendo el procedimiento los siguientes pasos: a) la aceptación automática, con un sistema de renderización (130), de un trabajo de renderización y el archivo de juego (502) por medio de Internet (110), comprendiendo el sistema de renderización (130)un servidor de trabajo (132) y una pluralidad de clústers de renderización (140), cada uno de dichos clústers comprendiendo un ordenador (141) y una consola de juego diferente (142) configurada para renderizar el archivo de juego como audio y vídeo, operando el ordenador (141) una tarjeta de captura (144), siendo el sistema de renderización (130) operable como una plataforma de doble propósito que admite su uso como banco de pruebas para control de calidad, y determinando el servidor de trabajo (132) si los trabajos de renderización o los de control de calidad reciben mayor prioridad; b) el envío con el servidor de trabajo (132) del trabajo de renderización al ordenador (141) de un clúster de renderización seleccionado de entre una pluralidad de clústers (140); c) la orden con el ordenador (141) en el clúster de renderización seleccionado (140) a la consola de juego (142) en el clúster de renderización seleccionado para que cargue y repita el archivo de juego para así renderizar automáticamente el archivo de juego como audio y vídeo (504); d) la captura automática, con la tarjeta de captura (144) operada por el ordenador (141) en el clúster de renderización seleccionado (140), el audio y vídeo renderizado para el archivo de juego como un archivo de audio/ vídeo (505); y e) la proporción automática, con el sistema de renderización (130), del archivo de audio/ vídeo (506) a través de Internet (110); a través del cual un receptor del archivo de audio/ vídeo puede visualizar la acción representada por el archivo de juego de otro modo que no requiera una copia del juego correspondiente.

Description

DESCRIPCIÓN

Procedimiento y dispositivo para la renderización en línea de archivos de juego

CAMPO DE LA INVENCIÓN

La presente invención se refiere a videojuegos que son capaces de grabar la acción dentro de un juego para su posterior reproducción dentro del juego. De manera más particular, la presente invención toma dicha grabación, la renderiza y captura el resultado en un archivo de audio o vídeo, para su posterior reproducción sin el juego.

ANTECEDENTES DE LA INVENCIÓN

Una característica popular de los videojuegos actuales, como en los deportes televisados, es la “repetición instantánea”. Esta característica permite que un juego o evento que acaba de ocurrir en vivo vuelva a mostrarse al jugador/es o a un público.

Para el caso de los deportes televisados, se graba y quizás comprime la señal de vídeo de cada una de las cámaras que cubre la acción. Para lograr una repetición instantánea, se repite una o más de esas grabaciones. Si para la reproducción se selecciona una cámara diferente a la que se había seleccionado originalmente, entonces el público podrá experimentar el mismo juego o evento desde un punto de vista diferente. En algunos deportes, los jueces o árbitros presentes en el evento en vivo pueden usar la tecnología de “repetición instantánea”, pero como modo de revisar el juego o evento desde una perspectiva diferente a su propia experiencia del juego.

En los videojuegos, la tecnología es diferente. La grabación del vídeo es una carga pesada en términos informáticos que a menudo ni siquiera es soportada por el hardware de la consola de juego, donde la renderización del audio y los gráficos de vídeo son ejecutados por chips dedicados cuyas salidas podrían no ser accesibles para su captura por un procesador principal. Además, normalmente resulta natural que los videojuegos hagan un uso máximo de los recursos informáticos, de modo tal que poca compatibilidad en exceso quede sin usar. Por lo tanto, aún cuando sea posible, la captura de vídeo para reproducirlo posteriormente, incluso desde el punto de vista del jugador original, limitará de manera severa las otras características del juego, por ejemplo, la complejidad de los gráficos, la cantidad de jugadores, el número de objetos del juego, etc.

Para superar esta limitación, muchos juegos modernos en lugar de esto capturarán un “archivo de juego”. Un “archivo de juego” contiene datos que indican el estado del juego en uno o más puntos (por ejemplo, el estado inicial al comienzo del juego, o un punto de control en algún estado intermedio durante el juego), así como también datos periódicos o con marcas de tiempo que resultan necesarios para reproducir la secuencia original de eventos en el juego. Dichos datos periódicos o con marcas de tiempo pueden representar, por ejemplo, presiones de botones del controlador del juego. Esto requiere que el juego sea sustancialmente determinista: Al iniciar en un estado específico, con eventos de entrada específicos aplicados en tiempos específicos, el resultado del juego será exacta o esencialmente el mismo.

En un juego con un solo jugador, los únicos eventos que pueden afectar un juego determinista son aquellos ingresados por el jugador. Tales eventos de entrada pueden incluir entradas simples del controlador, como presionar o soltar botones, lecturas periódicas de la palanca de mando o actualizaciones de posición de dicha palanca. Los eventos de entrada también pueden venir como los resultados del procesamiento de entradas de control más complejas. Por ejemplo, una entrada de control compleja puede ser el análisis de vídeo desde una cámara que mira al jugador: Cuando se analiza el vídeo de los movimientos del jugador, el sistema puede reconocer un gesto predeterminado (por ejemplo, una onda) o un valor (por ejemplo, un ángulo en el que se inclina el cuerpo del jugador) que produce un evento de entrada. Otro ejemplo de una entrada de control compleja es una entrada de audio de un micrófono que monitorea la voz de un jugador: La aplicación de un algoritmo de reconocimiento del habla puede reconocer comandos orales o el nivel de énfasis en la voz del jugador, donde un comando o valor de énfasis reconocido se convierte en un evento de entrada.

En un juego con jugadores múltiples, es posible grabar los eventos de entrada producidos por cada uno de los jugadores. Esto es común cuando todos los jugadores tienen controladores separados en la misma consola. Sin embargo, en un juego con jugadores múltiples distribuidos, donde diferentes jugadores tienen consolas separadas conectadas mediante un canal de comunicaciones (por ejemplo, un enlace infrarrojo, Bluetooth (TM), una red de área local por cable o inalámbrica, una red telefónica o Internet), podría bastar con grabar solo los mensajes enviados entre las consolas. En algunos juegos con jugadores múltiples distribuidos, los eventos de entrada de cada jugador son procesador por la consola correspondiente y resultan en cambios de estado de objetos en el juego, que después se comparten. Dicha elección de implementación se puede hacer porque los datos que representan los cambios en los objetos en el juego son inferiores a los datos que representan los eventos de entrada, o porque los eventos de entrada de todos los jugadores son una carga muy grande. Por ejemplo, cuando se usa una entrada de la palanca de mando para apuntar, determinar el objetivo actualmente seleccionado puede ser un cálculo costoso, por lo que en lugar de intercambiar el valor actual de la palanca de mando y requerir a todas las consolas participantes que calculen el objetivo actualmente seleccionado, la consola a la que se encuentra adjunta la palanca de mando puede determinar el objetivo y enviar la identidad del objetivo a las demás consolas. Enviar eventos de entrada sin procesar, en comparación con actualizaciones de objetos previamente procesados, es una decisión de implementación y puede variar incluso dentro de una aplicación de juego (es decir, en algunos casos se envían actualizaciones de objetos y en otros, eventos de entrada sin procesar).

Por lo tanto, los datos con marcas de tiempo a grabar en un archivo de juego pueden representar ya sea eventos de entrada de los jugadores o mensajes recibidos por una consola desde otros participantes del juego, o bien una mezcla de los anteriores. Un archivo de vídeo de este tipo se usa, por ejemplo, en Halo 3 (TM), publicado por Microsoft, Inc., de Redmond, WA, desde Setiembre de 2007.

Dado dicho “archivo de juego”, es posible lograr una repetición instantánea en una consola similar ejecutando el mismo programa de juego. El estado de juego, como se lo grabó en el archivo de juego, se usa para recrear el estado de juego en la consola como ocurrió en el juego original. Después, los datos con marcas de tiempo son proporcionados al motor del juego, en lugar de la entrada real de los controles del jugador u otras consolas. Esto puede ocurrir en tiempo real, en cuyo caso el audio y vídeo de la reproducción es similar, si no es idéntico, a lo que vio originalmente el jugador, o la consola de juego puede reproducir usando un reloj ralentizado, en cuyo caso la reproducción puede ser en cámara lenta.

Generalmente, los archivos de juego no pueden reproducirse hacia atrás, porque la naturaleza del modelo de juego no puede ejecutarse al revés. En algunas implementaciones, para soportar una capacidad de rebobinado, los archivos de vídeo incluyen puntos intermedios de control. Cada uno de estos puntos incluye un estado de juego, similar a aquel del estado inicial, desde el que puede iniciarse la reproducción del archivo de juego. Con los puntos intermedios de control, puede proporcionarse la característica de rebobinado para permitir que un jugador repita una parte de la acción de manera repetitiva, sin tener que comenzar siempre de nuevo al inicio del archivo de juego. En Halo 3 (TM) (op. cit.), los puntos intermedios de control están incluidos en el archivo del juego cada pocos segundos. Por lo tanto, al revisar la grabación de un juego, un usuario puede saltar hacia adelante o hacia atrás, hasta cualquier punto en el archivo, con una resolución temporaria de unos pocos segundos.

En algunas implementaciones, especialmente aquella de Halo 3 (TM), durante la reproducción de un archivo de vídeo, el usuario tiene la opción de alterar la posición de la cámara para que sea diferente de aquella que experimentó el jugador original. Por ejemplo, el jugador original podría haber estado jugando con la cámara configurada en el punto de vista (POV por sus siglas en inglés) de primera persona del personaje del jugador, es decir, el cuadro fue visualizado a través de los ojos del propio personaje del jugador. Sin embargo, en la reproducción, se puede cambiar la cámara para ver la acción desde el POV de otro personaje o desde atrás del personaje del jugador. En algunas implementaciones, la cámara puede volar por encima de la acción, ya sea que esté conectada a un personaje o limitada a ir delante de un personaje, ambas o ninguna: libre de volar y apuntar hacia cualquier sitio.

Solo resulta adecuado hacer ediciones menores a un archivo de juego. Por ejemplo, es posible grabar un desplazamiento de la posición original de la cámara durante una reproducción e incorporarlo a un archivo de juego editado. Depende de la implementación determinar si el desplazamiento es distinto de la posición original de la cámara, de modo tal que una opción de “usar la posición original de la cámara” puede estar presente en caso de que el usuario después decida que una porción de la grabación de la posición original de la cámara era preferida para la versión editada.

Con una grabación de sonido o vídeo, un editor tiene la capacidad de especificar un “punto de entrada” y “de salida” dentro de la grabación para identificar un segmento particular de la misma que se desea reproducir o copiar. Del mismo modo, se puede especificar un punto de entrada y/ o salida para un archivo de juego. Esto permite al usuario tener un archivo de juego completo que puede ejecutarse por quince minutos, para identificar una porción de interés. Por lo tanto, si un evento espectacular de treinta segundos, que valga la pena compartir, ocurrió a los siete minutos y dos segundos en un archivo de juego de quince minutos, es posible especificar un punto de entrada y salida que dirija la reproducción del recorte editado de modo tal que muestre sustancialmente solo la parte interesante seleccionada. Por lo tanto, al configurar los puntos de entrada y salida, el intervalo de juego en vivo representado por el archivo de juego puede ser una sesión completa o un intervalo de interés específico.

En algunas implementaciones, incluyendo Halo 3 (TM), es posible hacer que los archivos de juego editados sean más pequeños que el archivo original dejando de lado cualquier estado de juego y evento desde el inicio del archivo de juego hasta (pero sin incluir) el punto intermedio de control en o inmediatamente antes del punto de entrada especificado. Si no hubiese un estado intermedio de juego antes del punto de entrada, o no se hubiese configurado ningún punto de entrada, entonces el inicio del archivo no se recortará de este modo. También es posible acortar el archivo de juego editado dejando de lado todos los eventos y estados intermedios de juego que se produzcan después del punto de salida, si lo hubiere. En el ejemplo anterior, el archivo de vídeo de quince minutos se podría guardar como un archivo de juego editado con una duración solo de alrededor de treinta segundos (o ligeramente más, tal como se analizará a continuación).

En algunas implementaciones que permiten que un punto de entrada sea especificado como un número de tiempo o cuadro con una precisión superior a aquella del estado de juego anterior correspondiente (ya sea que se trate del estado de juego inicial o un punto intermedio de control), la consola de juego comienza a reproducir a partir del estado de juego inmediatamente anterior al punto de entrada especificado, pero mantiene el vídeo en blanco y el audio mudo hasta alcanzar el punto de entrada. Por este motivo, si un juego debiese guardar puntos intermedios de control cada cinco segundos, entonces el archivo de juego editado en el ejemplo de arriba contendría de treinta a treinta y cinco segundos de valor de datos, aún cuando los puntos de entrada y salida seleccionados estuviesen separados por treinta segundos.

Por lo tanto, un archivo de juego editado podría guardarse como un “archivo de juego recortado” y contener solo los estados intermedios de juego que son inmediatamente anteriores al punto de entrada y al de salida, y los eventos de juego que se encuentran entre ese primer estado de juego retenido hasta aquellos en el punto de salida. Sin embargo, en todo caso, un archivo de juego recortado sigue siendo un archivo de juego y se lo puede tratar del mismo modo, incluyendo la edición posterior. Al reproducirlo, el archivo de juego recortado resultante sigue asemejándose a un archivo de juego ordinario, pero la reproducción puede comenzar in medias res (en el medio de la acción). El tamaño reducido ocupa menos almacenamiento y es más fácil y menos costoso de compartir, ya que los tiempos de carga y descarga son reducidos.

La capacidad de alterar la perspectiva de la cámara durante la reproducción de un archivo de juego proporciona un mecanismo sofisticado de repetición instantánea, permitiendo que un jugador revise su propio juego, para determinar la razón de que una estrategia particular haya tenido éxito o fracasado. La adición de la configuración de puntos de entrada y salida para llegar rápidamente a la acción interesante (que puede incluir archivos de juego recortados o no) proporciona una buena manera de mostrar la ejecución a otros, ya sea con fines de instrucción o entretenimiento.

El Documento de los US 2007/0117635 describe el uso de una consola de juego para enviar datos internos del juego para un videojuego a un servidor capaz de retransmitir dichos datos a quienes no participan del videojuego.

El Documento de los US 2003/0038805 describe un motor de espectadores que recibe información que indica la ocurrencia del juego, en base a la cual puede generar datos del espectador que pueden proporcionarse a los espectadores.

El Documento de los US 2009/0118018 describe un servidor de aplicación/ juego 1521-1525 que implementa juegos o aplicaciones.

Sin embargo, existe una desventaja en los archivos de juego, ya que a fin de poder visualizarlos, un usuario debe contar con una consola de juego adecuada y una copia del juego. Esto está bien para los jugadores que usan los archivos de juego para la repetición instantánea, o quienes comparten archivos de juego con otros jugadores que ya poseen el juego, pero limita de manera severa el público para lo que de otro modo sería una agradable forma de entretenimiento.

OBJETIVOS Y RESUMEN DE LA INVENCIÓN

En las reivindicaciones independientes adjuntas 1 y 6, se definen, respectivamente, un procedimiento y sistema de acuerdo con la invención.

La presente invención permite que archivos de juego como aquellos analizados, editados o no, sean cargados a un servidor remoto que puede renderizar la reproducción del juego como un archivo de audio/ vídeo apto para su visualización fuera del juego en el que fueron grabados, ya sea en una consola similar o de otro modo. En particular, el archivo renderizado puede ser distribuido, por ejemplo, a través de Internet, y ser visualizado, por ejemplo, en un ordenador personal, como dentro de un navegador Web. El archivo de vídeo resultante puede ser transferido a DVD (utilizando software de autoría de DVD, que puede incluir una transcodificación, de ser necesario) o editado, usando un software de edición de vídeo para combinarlo con otros archivos de vídeo similares, y/ o puede alterarse la pista de audio.

Desde un archivo de juego, esta invención produce convenientemente un archivo de audio/ vídeo que puede ser distribuido a personas que no cuentan con el disco (o cartucho) de juego correspondiente o una consola compatible, y por lo tanto proporciona una fuente de entretenimiento más versátil que, más allá de meramente entretener, puede desafiar o enseñar a otros jugadores a intentar hazañas similares en el juego y persuadir a personas que no son jugadores para que adquieran la consola y/ o el juego.

La presente invención puede ofrecer una selección de resoluciones de salida para el archivo de vídeo resultante. Además, la presente invención puede configurarse para ofrecer sus capacidades a los usuarios como un servicio premium, contando, en algunas realizaciones, con mayores resoluciones de salida disponibles solo por pagar un importe mayor.

BREVE DESCRIPCIÓN DE LOS DIBUJOS

Los aspectos de la presente invención resultarán evidentes después de considerar la siguiente descripción detallada, tomada en conjunto con los dibujos que la acompañan, donde los personajes similares a los que se hace referencia se refieren a las partes similares de principio a fin, y en los que:

La FIG. 1 es un diagrama de bloque de una realización de la presente invención;

La FIG. 2 es una interfaz de usuario que muestra archivos de vídeo cargados que ofrecen una solicitud de renderización;

La FIG. 3 es un cuadro de diálogo para recolectar detalles durante una transacción de solicitud de renderización; La FIG. 4 es un recibo adecuado para rastrear el progreso o los resultados de la transacción de solicitud de renderización; y

La FIG. 5 es un diagrama de flujo para el proceso de renderización del archivo de juego de la presente invención. DESCRIPCIÓN DETALLADA DE LA INVENCIÓN

En referencia a la FIG. 1 consola de juego 101-104 se puede usar de manera individual o en una configuración de nodos múltiples 100 en la que las consolas 101-104 se comunican entre sí a través de una red de área local (LAN por sus siglas en inglés; no se muestra) y/ o Internet 110. Es posible que haya una configuración de jugadores múltiples en una única consola o con diferentes jugadores que usan las consolas que operan en una configuración de nodos múltiples, o ambas opciones. En la configuración de nodos múltiples 100, cada una de las consolas participantes cuenta con una copia del programa de juego siendo ejecutado, ya sea de un archivo, cartucho o disco local; o descargado mediante un canal de comunicación que los enlaza.

Cualquiera de las consolas 101-104 además puede comunicarse a través de Internet 110 con un sistema de servidor de base de datos 120 generalmente mantenido en un centro de datos 121 por cuestiones de confiabilidad y la capacidad de una alta disponibilidad de ancho de banda (aunque estas características no son estrictamente requeridas).

El sistema de servidor de base de datos 120 incluye un servidor de red de juegos 122 que puede proporcionar, entre otros servicios, una sala de juegos, por medio de la cual un jugador en una consola 101 preparado para participar de un juego particular puede descubrir a otros jugadores preparados de manera similar en otras consolas 102-104. Otros servicios disponibles a través del servidor de red de juegos 122 pueden incluir el mantenimiento de cuenta, el historial de juego (por ejemplo, un listado de logros en el juego), una placa de clasificación para identificar a los jugadores con puntajes altos, boletines relacionados con el juego y características de red social como foros y mensajería instantánea a otros jugadores.

En esta realización, el acceso al intercambio de archivos 123 se obtiene a través de un servidor de red 122, aunque se contemplan otras implementaciones. El intercambio de archivos 123 es un servidor dedicado a proporcionar acceso al almacenamiento 124. Cuando en una comunicación con el intercambio de archivos 123, una consola 101 puede cargar o descargar o de otro modo gestionar archivos de juego en el almacenamiento 124, pero solo de acuerdo con las políticas y reglas administradas por el intercambio de archivos 123. Por ejemplo, puede ser una política que cualquiera pueda descargar un archivo de juego a su propia consola para visualizarlo, pero que solo un jugador que cargue un archivo de juego tenga permitido eliminar dicho archivo o cargar actualizaciones del mismo, o bien hacer que ese archivo de juego sea renderizado. El intercambio de archivos 123 podría hacer cumplir estas políticas. El intercambio de archivos 123 ofrece preferiblemente una interfaz de servidor web 127 a la que un cliente Web 150 pueda tener acceso a través de Internet 110, por ejemplo, ejecutándola en una PC (aunque también podría ser ejecutada en una consola de juego similar a las 101-104, pero no exhibida). Como se observará en los análisis a continuación, un archivo de juego puede renderizarse a un archivo de audio/ vídeo, que también puede almacenarse por medio del intercambio de archivos 123 en el almacenamiento 124. También podría ser una política adicional mantenida por el intercambio de archivos 123 que dichos archivos de vídeo estuviesen disponibles para un cliente Web 150 a través de la interfaz del servidor Web 127, pero esos archivos de juego no.

El intercambio de archivos 123 puede comunicarse con un servidor de trabajo 132 que puede estar ubicado en otro sitio que no sea el centro de datos 121, mostrado aquí como el centro de renderización 131, especialmente cuando no se requieran altos grados de confiabilidad y disponibilidad y los recursos físicos utilizados para renderizar archivos de juego como archivos de vídeo puedan asignarse de otro modo, tal como se analiza a continuación. Esto se debe a que, a diferencia de los servicios ofrecidos por el servidor de red del juego 122 y el intercambio de archivos 123, si un trabajo de renderización falla en su procesamiento o transporte, es posible volver a intentarlo sin que haya una pérdida permanente. La comunicación entre el intercambio de archivo 123 y el servidor de trabajo 132 es a través de una interfaz dedicada 125 que puede emplear un enlace o canal de comunicación segura 126 (por ejemplo, una conexión de enchufe seguro o una conexión de red privada virtual, VPN por sus siglas en inglés) a través de Internet 110 a un servidor de trabajo 132. El uso de un enlace seguro 126 minimiza la exposición tanto del intercambio de archivos 123 como del servidor de trabajo 132 a una interrupción o acceso no autorizado.

Después de completar un juego, por ejemplo, que involucre a un jugador en una consola 101, ese jugador podrá usar una interfaz dentro del juego (no se muestra) para cargar el archivo de juego al almacenamiento 124 por una comunicación con el intercambio de archivos 123, normalmente a través de un servidor de red de juego 122. El jugador en la consola 101 (o, si las políticas lo permiten, otro usuario en una consola diferente 102-104 o usando un cliente Web 150) puede solicitar que el archivo de juego cargado en el almacenamiento 124 se renderice a un archivo de audio/ vídeo (analizado con más detalles a continuación, en conjunto con la FIG. 2). En respuesta a la solicitud, el intercambio de archivos 123 inicia una transacción para el renderizado, incluyendo la recolección de cualquier detalle necesario para especificar la renderización (analizado más detalladamente en conjunto con la FIG.

3). Es posible aceptar textos descriptivos del archivo de juego de parte del solicitante, por ejemplo un título para el recorte, o dicha información puede generarse automáticamente en base a los atributos del archivo de juego y sus metadatos (por ejemplo, el nombre del juego, entorno, jugadores, solicitante, etc.). La transacción puede incluir un pago u otro procedimiento de facturación asociado a la cuenta del solicitante. Se proporcionará un recibo electrónico por la transacción y se proveerá un estado actual del proceso de renderizado, como se muestra en la FIG. 4 y se analiza en detalle a continuación.

Una vez que un jugador o usuario ha proporcionado los detalles adecuados y se ha comprometido con una transacción para el renderizado, el intercambio de archivos 123 envía un trabajo de renderizado que comprende el archivo de juego (o una referencia al mismo) y los detalles de renderizado para un sistema de renderizado 130 sobre un enlace seguro 126. En la implementación mostrada, el sistema de renderización 130 comprende un servidor de trabajo 132 y uno o más clústers de renderización 140, cada uno de los cuales comprende un ordenador 141, normalmente PC, que recibe órdenes del servidor de trabajo 132 y a su vez controla una o más consolas 142. La comunicación entre el servidor de trabajo 132 y todos los ordenadores 141 (se muestra uno) y entre ordenadores 141 y consolas 142 puede tener lugar mediante redes separadas, o como se muestra, por medio de una única LAN 133 proporcionada por uno o más interruptores (implícitamente mostrados como LAN 133). En general, las consolas 142 son sustancialmente similares a las consolas 101-104 pero para las consolas comercialmente disponibles en mayor medida en la actualidad necesitan ser la versión de desarrollador de la consola. Esto se debe a que las consolas para el consumidor 101-104 generalmente implementan varias características de seguridad o eliminan otras de gestión externa a fin de reducir la probabilidad de manipulaciones no autorizadas. Sin embargo, las consolas de desarrolladores a menudo ofrecen gestión remota y las características de control no se encuentran disponibles en la versión para el consumidor. Un ejemplo de dos productos que presentan dicha diferenciación son la Xbox-360 de Microsoft Corporation y la Consola para Desarrolladores Xbox-360, de la misma compañía, donde un servicio de Telnet que permite control remoto a una consola es proporcionado por la Consola para Desarrolladores Xbox-360, pero no por la consola Xbox-360 disponible para los consumidores. Cabe señalar que para una implementación en que las consolas 101-104 se implementan como ordenadores personales, las consolas 142 se implementarían de manera similar como ordenadores personales.

Cuando un servidor de trabajo 132 recibe un trabajo de renderización, despacha el trabajo de renderización a un ordenador 141 en un clúster de renderización 140. Si todos los clústers de renderización 140 están ocupados, el servidor de trabajo 132 puede poner en cola el trabajo de renderización. Al recibir el trabajo de renderización, el ordenador 141 puede dar la orden a una consola disponible 142 de que cargue el archivo de juego correspondiente al trabajo de renderización, y cuando la carga haya sido completada, ordenar a la consola 142 que repita el archivo de juego de acuerdo con los detalles asociados, por ejemplo, la resolución solicitada. Cuando la consola 142 obedece, la salida de audio y vídeo de la consola 142 es transportada por una salida 143, por ejemplo, una conexión HDMI, a una tarjeta de captura correspondiente 144, también operada por, y tal vez contenida dentro, del ordenador 141. En el caso de la Consola para Desarrolladores Xbox-360, que sí ofrece salida HDMI, una tarjeta de captura 144 adecuada para este fin es la Intensity Pro, fabricada por Blackmagic Design de Melbourne, Australia, cuyos controladores actuales pueden soportar tarjetas de captura múltiples en el mismo ordenador 141. El ordenador 141 configura la tarjeta de captura correspondiente 144 en la resolución y formato de archivo adecuados (así como otros detalles, según sea adecuado) y dirige el audio/ vídeo capturado de la salida 143 a un archivo. Al ejecutar el trabajo de renderización, el ordenador 141 se asegura de que la tarjeta de captura correspondiente 144 esté lista y capture a más tardar al tiempo en que la salida de la consola correspondiente 142 alcance el punto de entrada especificado en el archivo de juego.

Cuando la consola 142 alcance el punto de salida del archivo de juego, el ordenador 141 dará la orden a la tarjeta de captura 144 de cesar la captura y el audio/ vídeo resultante se cerrará, pero esto no sucederá antes del punto de salida del archivo de juego. El archivo de vídeo resultante regresa al servidor de trabajo 132 y es posteriormente transmitido al intercambio de archivos 123 para residir en el almacenamiento 124.

A lo largo del proceso de renderización, en algunas realizaciones, el servidor de trabajo 132 puede rastrear el estado de un trabajo de renderización, ya sea por medio del ordenador de sondeo 141 o a partir de las actualizaciones de cambio de estado recibidas del ordenador 141. Dichas actualizaciones pueden ser transmitidas de regreso al intercambio de archivos 123 para actualizar el estado, tal como se muestra en el recibo de la transacción (analizado en conjunto con la FIG. 4).

Uno o ambos ordenadores 141 y el servidor de trabajo 132 pueden intentar ordenar y despachar trabajos de renderización para optimizar el rendimiento. Por ejemplo, cuando una consola 142 se alista para transmitir un archivo de juego, se requiere cierta cantidad de configuración. En particular, si aún no están presentes, deberán cargarse los modelos del entorno y objetos a los que hace referencia un archivo de juego. En Halo 3 (TM) y otros productos, “mapa” hace referencia a la combinación de modelos, texturas, sonidos de ambiente, etc., que comprenden el entorno y los objetos. Muchos archivos de juego diferentes pueden hacer referencia al mismo conjunto de modelos (mapa). Un ordenador 141 puede optimizar el uso de una consola 142 proporcionando una consola 142 con archivos de juego consecutivos que en su totalidad usan los mismos modelos de entorno y objetos (es decir, el mismo mapa), de ese modo evitando la necesidad de cargar siempre el entorno, etc. para cada renderización posterior. El servidor de trabajo 132 puede participar de esta optimización prefiriendo enviar trabajos de renderización con el uso de un entorno particular a clústers de renderización particulares 140.

Cabe señalar que una configuración hardware de un sistema de renderización 130 en la que un servidor de trabajo 132 se comunica directa o indirectamente (por ejemplo, a través de un ordenador 141) con un conjunto de consolas de desarrollador 142 es algo que se ve comúnmente en el desarrollo de juegos de consola para su uso como un banco de pruebas de control de calidad. La operación habitual de dicha configuración es permitir que nuevas compilaciones de un juego en desarrollo se sometan automáticamente a una batería de pruebas estandarizadas y automatizadas (el mecanismo para el envío de dicha ejecución de pruebas es muy conocido y no se describe de manera detallada en la presente invención, y por lo tanto no se muestra en las figuras). Cualquier fallo de una nueva compilación será detectado automáticamente por el ordenador 141 o el servidor de trabajo 132 y podrá ser señalado al desarrollador de modo tal que el problema que produce el fallo pueda ser analizado y abordado. Como el fallo se puede recrear a través de la repetición de la misma secuencia de prueba, no se requiere de un juego ni de la captura de vídeo. No obstante, con la introducción de las tarjetas de captura 144 a dicho sistema, la característica de prueba se transforma en una plataforma de propósito doble que da lugar a una implementación del sistema de renderización 130. Esta transformación aún deja el sistema utilizable como centro de pruebas, permitiendo de ese modo un uso muy eficiente de estos recursos. Por ejemplo, el servidor de trabajo 132 puede estar dirigido a priorizar trabajos de control de calidad durante un período de desarrollo particularmente pesado, el cual puede resultar en esperas más largas para que un trabajo de renderización se complete. En otras ocasiones, por ejemplo, durante torneos patrocinados o eventos de marketing, los trabajos de renderización recibirían la prioridad más alta.

Si es posible especificar diferentes resoluciones de salida de vídeo en el trabajo de renderización, habrá un número de opciones disponibles y las mismas podrán seleccionarse manual o automáticamente de acuerdo con la política. Por ejemplo, si un trabajo de renderización especifica una salida de alta definición (por ejemplo, en qué parte la salida presenta 1080 líneas de resolución), entonces las salidas de menor resolución (por ejemplo, aquellas con 720 o 480 líneas de salida) también se proporcionarán. El hecho de que dichas resoluciones más bajas deban ser explícitamente solicitadas y que sean renderizadas como repeticiones sucesivas del mismo archivo de juego, o que el archivo de salida de alta definición sea reducido mediante un proceso de escalamiento de imágenes individual realizado por ordenador 141, u otro dispositivo, es una cuestión de implementación y política.

Independientemente, todos los archivos de vídeo resultantes y los atributos asociados (por ejemplo, título, descripción, etc.) son colocados en el almacenamiento 124 y puestos a disposición de los clientes Web 150 y tal vez las consolas 101-104 (en caso de que los archivos de audio/ vídeo sean adecuados para su ejecución en las consolas). De manera alternativa o adicional, los archivos resultantes pueden ser publicados automáticamente en servicios de intercambio multimedia generados por el usuario, por ejemplo, aquellos proporcionados en YouTube.com, un sitio Web gestionado por YouTube, LLC de San Bruno, CA. Si, como suele ser el caso, los servicios de intercambio externos se limitan a una resolución particular y restringida, entonces, en general, el formato de menor resolución proporcionado por el centro de renderización 131 debería ser proporcionado al servicio externo.

Ahora, pasando a la FIG. 2, se muestra una interfaz del usuario 200, como puede presentarse en las consolas 101­ 104 o el cliente Web 150, para la creación de una transacción que solicita que un archivo de juego sea renderizado a un archivo de audio/ vídeo. La interfaz 200 puede requerir que un usuario (es decir, un jugador) haya iniciado sesión, cuya realización exitosa es indicada por la exhibición del nombre de usuario 201. Es posible enumerar el estado y las características de las redes sociales, tal como ejemplifica la cuenta de “amigos en línea” 202. Para mantener una cuenta de usuario segura, debe haber un botón de cerrar sesión 203. Puede proporcionarse un menú de alto nivel 210, por ejemplo, para acceder a diferentes servicios disponibles. Es posible que se muestre un resumen de la historia del jugador 220, incluyendo un nombre en pantalla 221 y los puntajes y logros de ese jugador. Se puede acceder a más detalles de la historia del jugador a través del sub-menú 230 que incluye la pestaña de archivos 231. La pestaña de archivos 231 proporciona el acceso a y la gestión de objetos en el almacenamiento 124 o el intercambio de archivos 123. El hecho de cargar un archivo de juego a un intercambio de archivos 123 se produciría desde dentro de un juego que se usa, por ejemplo, en las consolas 101-104 y como tal no está representado en la interfaz 200. Sin embargo, el menú de intercambio de archivos 240 incluye un elemento de menú 242 para archivos de juego ya cargados (lo cual se muestra en la FIG 2 como siendo seleccionado por el ícono de selección actual 241) y un elemento de menú para vídeos renderizados 243 (no se muestran como seleccionados hasta la FIG. 4).

En el elemento del menú 242 seleccionado, la información sobre archivos de juego cargados se muestra en un listado de archivos de juego 260. Los contenidos del listado de archivos de juego 260 puede filtrarse usando las herramientas en la barra de filtro 250, como el selector de tipo 251, el selector de fecha 252 y/ o el cuadro para ingresar texto mediante el teclado 253. Los criterios de filtro seleccionados con los elementos 251-253 pueden ser impuestos por el botón de enviar 254, lo que hará que los resultados se reduzcan a un listado de archivos de juego 260 que solo incluya aquellos que coincidan con los criterios de filtro especificados.

En este ejemplo, el listado de archivos de juego está compuesto de entradas 261-263. Si se hallasen más entradas legibles en el área de presentación del listado de archivos de juego 260, entonces se proporcionarán barras de deslizamiento o controles de cambio de página (no se muestra ninguno).

Cada entrada en un listado de archivos de juego 260 puede contener un título 270, una fecha de creación 272, el nombre de pantalla del autor 273, la clasificación 271, un contador de descargas 275, la duración 276 y el tipo de juego 277, 277' Y 277”. El archivo de juego puede ser representado por un ícono 281, pero como dicho ícono se necesita antes de que cualquier trabajo de renderización haya sido emitido, el ícono 281 es genérico ya sea para cualquier archivo de juego (no se muestra) o cualquier archivo de juego que use un entorno particular, el cual, para el ícono 281 es el mapa de “The Pit” según lo identifica el atributo del mapa 278. Por lo tanto, en este ejemplo en que las entradas de archivos de juego 261 y 263 tienen atributos de mapas comunes 278' y 278” (ambos son “Valhalla”), sus íconos correspondientes 281' y 281” son idénticos. Sin embargo, como la entrada 262 tiene un atributo de mapa diferente 278 (“The Pit”), su ícono 281 es diferente. Si bien aquí no se los muestra, los íconos 281, 281' y 282” podrían ser alternativa o adicionalmente diferenciados por los atributos de tipo de juego 277, 277' y 277”.

Cada entrada es un listado de archivos de juego 260 y también está acompañada por controles, por ejemplo el botón de descargar archivo de juego 274 (tire el archivo de juego asociado hacia dentro de una consola 101-104 para una posterior reproducción dentro del juego correspondiente del listado en el botón 274 (“Halo 3” en este caso). Cabe señalar que la fecha de creación 273 es la fecha en que se grabó el archivo de juego original, es decir, es la fecha cuando se jugó originalmente el juego y no la fecha en que el mismo fue editado (si así fue) ni la fecha de carga. Estas otras fechas también podrían ser presentadas o disponibilizadas por ejemplo a través del botón de “más detalles” 279. Por último, el botón de renderizar archivo 280 es proporcionado para iniciar una transacción de renderización del archivo de juego asociado.

Al presionarlo, el botón de renderizar archivo 280 comienza la transacción solicitando más detalles al usuario mediante el cuadro de diálogo de detalles 300, tal como se muestra en la FIG. 3. Dentro del cuadro de diálogo 300, la pantalla de atributos del archivo de juego 362 es sustancialmente similar a la entrada correspondiente 262 en la interfaz 200 de la Figura 2. Como tal, existe una correspondencia entre los títulos 370 y 270, la fecha de creación 372 y 272, la clasificación 371 y 271, el autor 373 y 273, el contador de descargas 375 y 275, la duración 376 y 276, tipo de juego 377 y 277 y el mapa 378 y 278. Por cuestiones de conveniencia, los botones de control, como el de descarga 374 para descargas (similar al botón 274) y el botón de detalles 379 (similar al botón 279 (para más detalles también se encuentran presentes. Los botones seleccionables 302 y 303 han sido recientemente presentados. En este ejemplo, dichos botones son para definición estándar y alta definición, respectivamente, ambos en Vídeo Multimedia de Windows (WMV por sus siglas en inglés), un formato de archivo de vídeo comprimido que promueve Microsoft Corporation. Otros detalles podrían incluir una selección de cuadros por segundo alternativos o formatos de archivo alternativos (por ejemplo, MPEG 4), etc. (no se muestra ninguno). El botón de siguiente 305 confirma la transacción y envía un trabajo de renderización para que el archivo de juego sea identificado por la pantalla de atributos de juego 362 con los detalles seleccionados, por ejemplo, con los botones 302 y 303. Si el solicitante desea cancelar la transacción sin una renderización, puede hacer clic en un cuadro que desaparece 301 y el cuadro de diálogo 300 se cerrará.

Si hubiese un pago a facturar o cobrar, podría ser diferente para las distintas selecciones ofrecidas en el cuadro de diálogo 300. Si este es el caso y hay suficientes créditos disponibles para una selección (por ejemplo, la renderización de definición estándar seleccionable con el botón 302), pero el solicitante no tiene crédito suficiente para otras selecciones (por ejemplo, la renderización de alta definición seleccionable con el botón 303), entonces un botón de “Necesito más minutos” 304 puede iniciar un proceso para aumentar la cantidad disponible de créditos disponibles. (Cabe señalar que en el ejemplo de la FIG. 3 y el botón 304, el término usado para la noción de “créditos” es “minutos”).

Una vez que la transacción es enviada con el cuadro de diálogo 300, se presenta al solicitante la interfaz de recepción 400 que se muestra en la FIG. 4. En la interfaz de recepción 400, los elementos superiores 201-204, 210, 220, 230 y 231 son los mismos que en la interfaz 200. Sin embargo, en el menú de intercambio de archivos 440 (en lugar del 240), el ícono de elemento seleccionado 441 indica el elemento del menú de vídeos renderizados 443 a estar activo y no el elemento del menú de intercambio de archivos 442. Por lo tanto, en lugar de ver el listado de archivos de juego 260, se muestra el listado de archivos renderizados 460.

En el listado de archivos renderizados 460, cada archivo renderizado es representado por un entrada, como la entrada 462 (en la FIG. 4 solo se muestra una de ellas). La entrada de archivos renderizados 462 incluye muchos elementos que permanecen consistentes con los correspondientes de la entrada de archivos de juego 262, incluyendo el título 470 y 270, las fechas de creación 472 y 272, el nombre de pantalla de autor 473 y 273, la clasificación 471 y 271, el contador de descargas 475 y 275, la duración 476 y 276, el tipo de juego 477 y 277 y el atributo del mapa 478 y 278. Sin embargo, muchos detalles que aparecen al presionar el botón de “más detalles” 479 son específicos para el archivo renderizado (aunque algunos pueden corresponder al archivo de juego original también). Muchos detalles serán específicos para el archivo renderizado: La solicitud de renderización 490 representa el número de transacción correspondiente a la solicitud para producir un audio/ vídeo renderizado desde una entrada de archivo de juego 262. La fecha de la solicitud 491, la fecha de finalización 492 (o fecha de finalización estimada, como se muestra en la FIG. 4), la resolución 493 solicitada en el cuadro de diálogo de detalles de la transacción 300, el cargo 494 evaluado contra la cuenta del jugador indicado por el nombre de usuario 201 (señalando otra vez que, en este ejemplo, la facturación es en “minutos”), y el estado actual 495 “Actualmente renderizando la película”, que también se expresa como control deshabilitado 474 con la etiqueta “Ver pronto”. Cabe señalar que en algunos contextos, los detalles de la solicitud de la renderización pueden presentarse sin presionar el botón de detalles 479, por ejemplo, inmediatamente después de haber enviado una transacción desde el cuadro de diálogo 300.

Cuando el estado actual 495 dice “Renderización completa” (no se muestra) el botón de control 474 se habilita y dice “Ver ahora” (no se muestra). Presionar el botón de control 474 cuando indica “Ver ahora” (no se muestra) iniciaría una descarga y reproducción del archivo renderizado, en la resolución seleccionada.

En algunos casos, un trabajo de renderización puede fallar, en cuyo caso el estado actual 495 sería “Error” y el usuario puede ser dirigido a contactar al soporte (como se muestra) o a reenviar la solicitud de renderización (no se muestra). De manera alternativa, si un trabajo de renderización no alcanza el estado de finalizado dentro de una cantidad de tiempo predeterminada, el mismo podría volver a intentarse automáticamente o podría notificarse a un operador.

En una realización alternativa, las estadísticas como la clasificación 471 y el contador de descargas 475 pueden registrarse por separado de la clasificación 271 y el contador de descargo 275 del archivo de juego correspondiente.

En una realización alternativa de la presente invención, a diferencia de lo que se muestra en la FIG. 1, la consola individual 101 o una de las consolas 101-104 de la configuración de nodos múltiples 100 puede comunicarse directamente con el sistema de renderización 130 a través de Internet 110 (esta conexión directa no se muestra). En esta realización, las funciones del intercambio de archivos 123 y la funcionalidad de las interfaces de usuario 200, 300 y 400 serían proporcionadas por el juego siendo ejecutado en la consola (que puede ser una PC).

La FIG. 5 es un diagrama de flujo para un proceso de renderización 500 por parte de un sistema de renderización en línea, como sucede en el ejemplo incrustado en el sistema de renderización 130. La condición inicial para el proceso de renderización 500 es que un archivo de juego haya sido capturado del juego en vivo, como se muestra al comienzo 501. El archivo de juego es aceptado por el sistema de renderización 130 a través de Internet 110 en el 502. En una realización, una orden de renderizar el archivo de juego es aceptada en el 503, siendo que la orden incluye dichos detalles, tal como lo hemos analizado en conjunto con la FIG. 3. Sin embargo, en otra realización, donde dichos detalles son predeterminados, la orden de renderizar debe estar implícita, donde aceptar una orden en el 503 no es necesario. En respuesta a la aceptación del archivo de juego en el 502 y la aceptación de la orden en el 503 (de ser requerido), la renderización del archivo de juego es llevada a cabo por el sistema de renderización 130 en el 504, en el 505, el sistema de renderización 130 captura la salida de audio/ vídeo de la renderización como archivo multimedia. El archivo multimedia capturado en el 505 entonces es proporcionado a través de Internet 110 al solicitante u otros en el 506. El proceso de renderización 500 finaliza en el 507.

Como con todos estos sistemas, las características particulares del sistema, los detalles específicos de las interfaces de usuario y la ejecución de los procesos dependerán de la arquitectura usada para implementar un sistema de la presente invención, el sistema operativo de los servidores seleccionados, el ancho de banda y otras propiedades de la red seleccionada y el código escrito del software. No es necesario describir los detalles de dicha programación a fin de permitir que una persona con habilidades ordinarias en la técnica implemente los procesos descritos en esta invención y proporcionar interfaces de usuario y códigos adecuados para ejecutar el alcance de la presente invención. Los detalles del diseño de software y la programación necesaria para implementar los principios de la presente invención se entienden con facilidad en la descripción de la presente invención. Varias modificaciones adicionales de las realizaciones descritas de la invención específicamente ilustradas y descritas en esta invención resultarán evidentes para los expertos en la técnica, especialmente en vista de las enseñanzas de esta invención. Por lo tanto, si bien las realizaciones preferidas de la presente invención han sido descritas, se agradecerá que no se limiten a las mismas sino que sean realizadas de otro modo dentro del alcance de las reivindicaciones.

Claims (10)

REIVINDICACIONES

1. Un procedimiento para renderizar un archivo de juego (502) que representa un intervalo de juego en vivo de un juego correspondiente para que sea visible sin el juego correspondiente, comprendiendo el procedimiento los siguientes pasos:

a) la aceptación automática, con un sistema de renderización (130), de un trabajo de renderización y el archivo de juego (502) por medio de Internet (110), comprendiendo el sistema de renderización (130)un servidor de trabajo (132) y una pluralidad de clústers de renderización (140), cada uno de dichos clústers comprendiendo un ordenador (141) y una consola de juego diferente (142) configurada para renderizar el archivo de juego como audio y vídeo, operando el ordenador (141) una tarjeta de captura (144), siendo el sistema de renderización (130) operable como una plataforma de doble propósito que admite su uso como banco de pruebas para control de calidad, y determinando el servidor de trabajo (132) si los trabajos de renderización o los de control de calidad reciben mayor prioridad;

b) el envío con el servidor de trabajo (132) del trabajo de renderización al ordenador (141) de un clúster de renderización seleccionado de entre una pluralidad de clústers (140);

c) la orden con el ordenador (141) en el clúster de renderización seleccionado (140) a la consola de juego (142) en el clúster de renderización seleccionado para que cargue y repita el archivo de juego para así renderizar automáticamente el archivo de juego como audio y vídeo (504);

d) la captura automática, con la tarjeta de captura (144) operada por el ordenador (141) en el clúster de renderización seleccionado (140), el audio y vídeo renderizado para el archivo de juego como un archivo de audio/ vídeo (505); y

e) la proporción automática, con el sistema de renderización (130), del archivo de audio/ vídeo (506) a través de Internet (110);

a través del cual un receptor del archivo de audio/ vídeo puede visualizar la acción representada por el archivo de juego de otro modo que no requiera una copia del juego correspondiente.

2. El procedimiento de la reivindicación 1, donde el trabajo de renderización incluye los detalles para la renderización del archivo de juego, la consola de juego en el clúster de renderización seleccionado automáticamente renderiza el archivo de juego como el audio y vídeo de conformidad con los detalles, y el ordenador en el clúster de renderización seleccionado automáticamente captura el audio y vídeo a medida que el audio/ vídeo es renderizado de acuerdo a los detalles.

3. El procedimiento de la reivindicación 2, donde los detalles incluyen una resolución especificada.

4. El procedimiento de la reivindicación 2, donde los detalles incluyen un formato de archivo de audio/ vídeo.

5. El procedimiento de la reivindicación 1, donde el archivo de juego es un archivo de juego editado.

6. Un sistema (130) para la renderización de un archivo de juego (502) que representa un intervalo del juego en vivo de un juego correspondiente, de modo que sea visualizable sin el juego correspondiente, comprendiendo el sistema al menos un ordenador de servidor de trabajo (132) adaptado para la comunicación con Internet (110) y configurado para aceptar un trabajo de renderización en el archivo de juego a través de Internet, siendo el sistema (130) operable como una plataforma de doble propósito apta para su uso como banco de pruebas para control de calidad, determinando el al menos un ordenador de servidor de trabajo (132) si los trabajos de renderización o los de control de calidad reciben mayor prioridad; y

una pluralidad de clústers de renderización (140), cada uno comprendiendo un ordenador de clúster de renderización (141) y una consola de juego diferente (142), configurada para renderizar el archivo de juego como audio y vídeo, estando la consola de juego (142) dentro de cada clúster de renderización bajo el control del ordenador de clúster de renderización (141), donde el al menos un ordenador de servidor de trabajo (132) está adaptado para aceptar el trabajo de renderización y el archivo de juego a través de Internet (110), el al menos un ordenador (132) envía el trabajo de renderización al ordenador del clúster de renderización (141) de un clúster de renderización seleccionado de entre una pluralidad de clústers de renderización (140), operando el ordenador del clúster de renderización (141) del clúster de renderización seleccionado una tarjeta de captura (144), el ordenador del clúster de renderización (141) del clúster de renderización seleccionado ordena a la consola de juego (142) del clúster de renderización seleccionado cargar y repetir el archivo de juego para así renderizar el archivo de juego como audio y vídeo, la consola de juego (142) del clúster de renderización está adaptada para recibir el archivo de juego del ordenador del clúster de renderización (141) del clúster de renderización seleccionado, la consola de juego (142) del clúster de renderización seleccionado está adaptada para renderizar el archivo de juego como audio y vídeo en respuesta a la orden, siendo la tarjeta de captura (144) operada por el ordenador del clúster de renderización (141) del clúster de renderización seleccionado y capturando el audio y vídeo como archivo de audio/ vídeo, y con el archivo de audio/ vídeo proporcionado por el ordenador de servidor de trabajo (132) por medio de Internet (110), mediante el cual un receptor del archivo de audio/ vídeo puede visualizar la acción representada por el archivo de juego de otro modo que no requiera una copia del juego correspondiente.

7. El sistema de la reivindicación 6, donde el trabajo de renderización incluye los detalles para la renderización del archivo de juego y el archivo de audio/ vídeo es acorde a los detalles.

8. El sistema de la reivindicación 7, donde los detalles especifican una resolución y la consola de juego (142) del clúster de renderización seleccionado está adaptada para recibir la resolución proporcionada y para renderizar el archivo de juego en la resolución.

9. El sistema de la reivindicación 7, donde los detalles especifican un formato archivo de audio/ vídeo y el archivo de audio/ vídeo se proporciona en dicho formato de archivo.

10. El sistema de la reivindicación 6, donde el archivo de juego aceptado es un archivo de juego editado.