Desarrollo de Juegos para Decodificadores SATVD-T

Transcripción

1 Desarrollo de Juegos para Decodificadores SATVD-T Mariana Bernagozzi, Lautaro Woites, Federico Balaguer Lab. de Investigación y Formación en Informática Avanzada Facultad de Informática - Universidad Nacional de La Plata [mariana.bernagozzi lautaro.woites federico.balaguer]@lifia.info.unlp.edu.ar Resumen La puesta en marcha del SATVD-T pone a disposición de los productores y transmisores de contenidos una nueva tecnología que permite transmitir programas de televisión y aplicaciones. Ginga es la especificación de un middleware que da un ambiente uniforme para el desarrollo de servicios y aplicaciones en un decodificador de TV Digital. Una de las áreas de aplicación que se propone para Ginga y TVDi son juegos. Este tipo de aplicaciones suele tener demandas altas respecto a recursos como procesador y memoria. Los decodificadores son equipos con recursos limitados tanto en procesador como memoria. Este trabajo resume los avances realizados en nuestro laboratorio en lo que respecta al uso eficiente de los diferentes componentes del sistema de televisión digital para el desarrollo de juegos. 1. Introducción El Sistema Argentino de Televisión Digital Terrestre está basado en la norma Integrated Service Data Broadcasting (ISDB-Tb) en la que se definen formas para transmitir contenidos digitales por aire. Los contenidos digitales pueden ser programas de televisión y datos. Los datos pueden ser actualizaciones de software, o pueden ser sistemas de archivos (con aplicaciones NCL/Lua) [3]. El Sistema Argentino de Televisión Digital Terrestre (SATVD-T) se perfila como una posible plataforma para distribuir juegos considerándolos como un medio de expresión, como son otros contenidos que distribuye la televisión [6]. Cordeiro et al presenta la implementación de un Framework Java de juegos como una extensión a Ginga [7]. Este trabajo describe la experiencia de desarrollar juegos con otro lenguaje soportado por Ginga: NCL/Lua [2]. 2. Módulos del SATVD-T El Sistema Argentino de Televisión Digital Terrestre abarca una gama muy amplia de disciplinas. Las próximas secciones describen tres aspectos importantes para el foco de este trabajo: Creación del Flujo de Transporte, Recepción del

2 Figura 1: Transport Stream Flujo de Transporte y Ejecución de Aplicaciones NCL/Lua. El flujo de transporte o Transport Stream (TS) es una abstracción que encapsula todo aquello que se puede transmitir en una frecuencia UHF Creación del Flujo de Transporte El Flujo de Transporte según la norma ISDB define una estructura en donde existe la posibilidad de transmitir más de un programa televisivo en forma simultánea. A su vez, cada programa está dividido en diferentes servicios: video principal, múltiples audios, closed caption (CC), y carrousel de datos, entre otros. La Figura 1 muestra un diagrama donde se representa un ejemplo de un flujo de transporte. En el diagrama se distinguen tres grupos definidos (de arriba hacia abajo): flujo de transporte principal (MPEG2 TS), canal de metainformación (ISDB-Tb SI) y, por último, los parámetros de transmisión (Parametros TMCC). Dentro del flujo de transporte principal, se encuentran dos programas o subcanales (PMT1 y PMT2). En el diagrama, el PMT1 agrupa un video de alta definición (Video HD), un canal de audio, y el servicio de teletexto (CC). Generalmente los subcanales están definidos alrededor de un Video Principal al cual una aplicación (Ginga) está generalmente asociada dentro de un carrousel de datos[9,10,5], pero ésto no es mandatorio. La norma ISDB-T permite que múltiples aplicaciones viajen en un carrousel. Más aún, un PMT puede contener múltiples carrouseles de datos. En todo caso, los receptores son responsables de listar las aplicaciones Ginga asociadas de una u otra manera a un subcanal (que esta definido en un PMT data). La Figura 2 muestra un ejemplo del menú de un decodificador mostrando varias aplicaciones disponibles Recepción del Flujo de Transporte Un flujo de transporte como el mostrado en la Figura 1 es transmitido en una frecuencia UHF. Los receptores sintonizan las frecuencias UHF y procesan

3 Figura 2: Menú de Aplicaciones Disponibles estos Flujos de Transporte. De tal manera que en ocasiones cuando el televidente cambia de canal, en realidad el receptor sólo debe mostrar el siguiente sub-canal definido con otro PMT. Un receptor puede estar incorporado en un televisor o estar implementado como un dispositivo decodificador (set-top-box) que se conecta a un televisor o computadora. La Figura 3 muestra una vista general de los módulos que comprende un decodificador ISDB-Tb. La secuencia de eventos que ocurren cuando un decodificador recibe un Transport Stream se describe a continuación. Se recibe un Flujo de Transporte (BTS) que viene desde la antena el cual ingresa en el Sintonizador. El Sintonizador selecciona uno de los programas (representado como un PMT) y lo envía al Procesador de TS. El Procesador de TS separa el audio y video (señal tradicional de TV) de los paquetes que representan el Flujo de Datos. El audio y video son procesados y renderizados según la salida que esté activa en el receptor. El Flujo de Datos se conoce como carrousel de datos debido a que se transmite en forma cíclica. Este flujo se utiliza para crear un sistema de archivos (también conocido como carrousel de objetos) el cual contiene programas NCL/Lua y archivos de datos. Las capacidades del receptor marcan el límite de los juegos que se podrán ejecutar. Por ejemplo, receptores basados en chipset ST 7101 cuentan con un procesador de propósito general de entre 200 y 300Mhz, procesadores dedicados para renderizar la señal de televisión (audio y video) y una memoria de 256 MBytes. La memoria es compartida entre los módulos de decodificación (audio y video), un disco volátil (ram-disk) y memoria volátil de trabajo. Al final de cuentas, la memoria de trabajo para Ginga es cercana a los 20 MBytes. Dentro

4 Figura 3: Esquema del Receptor ISDB-Tb de la familia del chipset ST existen modelos que implementan OpenGL en forma nativa, pero éstos son para decodificadores de alta gama y mayor costo Ejecución de Aplicaciones NCL/Lua Una aplicación NCL/Lua puede correr en pantalla completa o también puede correr junto con el video principal, compartiendo la pantalla. Las aplicaciones NCL/Lua tienen la posibilidad de procesar eventos de dos tipo: eventos de Flujo de Transporte y eventos de Control Remoto (generados por el televidente). La ejecución de aplicaciones NCL/Lua se basa en dos elementos fundamentales. Primero, la existencia de un carrousel de objetos que contiene las aplicaciones a correr y los archivos de datos. Segundo, la señalización por medio de eventos que llegan por el Flujo de Transporte (BTS). Los eventos le indican al receptor como debe lanzar la aplicación NCL/Lua. Un posible escenario es cuando el receptor debe lanzar la aplicación de manera inmediata. Otro posible escenario es cuando el receptor debe lanzar la aplicación transcurrido un cierto tiempo asociado con el video principal. Otro posible escenario es cuando el receptor debe esperar que el televidente arranque la aplicación por sí mismo. Los documentos NCL definen regiones (de la pantalla), recursos multimediales y eventos. La estructura de un documento NCL puede dividirse en tres partes [11]: Encabezado del Documento Esta sección describe la meta-data del formato XML que sigue el resto del documento. Encabezado del Programa Esta sección tiene tres partes: regiones, descriptores de medios y conectores Cuerpo del Programa Esta sección describe la relación entre regiones, medias, eventos y los estados que tendrá la aplicación. La Figura 4 muestra una porción de código NCL que maneja la recepción del evento de botón rojo. Esta porción de código es parte de las aplicaciones que se presentan en este trabajo en la Sección 3.

5 <link xconnector="onkeyselectionset"> <bind component="background" role="onselection"> <bindparam name="keycode" value="red"/> </bind> <bind component="redimg" role="start"/> </link> Figura 4: Código NCL que define el manejo del botón rojo En la definición de un programa NCL, los scripts Lua son tratados como una Media más. Ésto es, es un elemento del programa que puede ser iniciado y detenido. Además, scripts Lua pueden definir funciones como co-rutinas. La norma ISDB-Tb especifica que los scripts Lua tiene acceso a los siguientes módulos: Sistema de Eventos que permite manejar los eventos del sistema de manera uniforme entre Lua y NCL. Se definen primitivas para enviar, recibir y crear eventos. Canvas que define una acceso a un layer transparente para dibujar texto y elementos gráficos. Se definen primitivas de dibujo de elementos geométricos simples y texto. Además los scripts Lua tiene acceso a otros módulos definidos en ese lenguaje, el más sobresaliente es posiblemente lua.sockets. Por otro lado, los scripts Lua no pueden utilizar funciones de la librería que modifiquen el estado persistente del decodificador, por ejemplo un script Lua no debería poder modificar un archivo que sea parte del carrousel de datos o de la memoria interna (compact flash) del decodificador. 3. Juegos Desarrollados Balaguer et al presenta el primer juego desarrollado en el grupo de TV Digital del Lifia denominado: Flechas y Colores [4]. Éste es un juego casual que busca ejercitar el uso de las teclas de color y las teclas de navegación (flechas). Para validar las diferentes partes del middleware, se desarrollaron diferentes tipos de juegos: se hicieron pruebas con juegos de lógica similares a Denki Blocks![8] y Flood-It[1]; y también se implementaron juegos tradicionales como el Snake, Sokoban y Tateti. Pueden verse capturas de pantalla de algunos de estos juegos en la Figura 5. En la mayoría de los juegos desarrollados, el rendering de gráficos, manejo de eventos de teclado (control remoto) y la lógica del juego están implementados íntegramente en Lua. La aplicación NCL simplemente contiene una media Lua que ocupa toda la pantalla. Para el rendering de gráficos se utilizaron primitivas del módulo canvas y para el manejo de eventos del control remoto se hizo uso del módulo event. Lua, al ser un lenguaje de script y debido a su sencillez, velocidad y tamaño, es un lenguaje muy adecuado para codificar la lógica de los juegos.

6 (a) Flood-it! (b) Snake. (c) Sokoban. (d) Tateti. Figura 5: Capturas de pantalla de los juegos desarrollados. Sin embargo, el módulo canvas es muy limitado, haciendo que sea engorroso el desarrollo de juegos atractivos visualmente. El juego Tateti no está desarrollado íntegramente en Lua. La navegación sobre el tablero está programada en NCL haciendo uso del atributo focusindex, links y conectores. El rendering gráfico se realiza en forma compartida entre NCL y Lua: las medias gráficas están definidas y ubicadas usando NCL mientras que con Lua se resuelve dinámicamente las imágenes que se deben mostrar en cada caso. Para saber cual es el turno del jugador actual y para verificar la existencia de un ganador se utiliza Lua. Para juegos como Snake, que renderizan en forma continua, fue un problema la ausencia de un mecanismo preciso para el manejo de eventos de tiempo. No fue posible utilizar la función sleep dentro del manejador de eventos ya que la misma no permitía que otros eventos sean procesados, por lo que se optó por utilizar la función event.timer(ms, f), la cual dispara un temporizador que realizará una llamada a la función f luego de ms milisegundos. Una desventaja de la utilización event.timer es que la función que f no puede recibir parámetros. En los juegos Denki Blocks! y Flood-It la pantalla es borrada y redibujada completamente en cada turno del juego. En un principio, se utilizó esta misma modalidad para los juegos Sokoban y Tateti, pero como el redibujado de la pantalla es una operación costosa, los juegos no tenían una buena performance

7 cuando se corrían en un STB. Luego se optó por repintar solamente las áreas de la pantalla que son necesarias en cada turno del juego y se logró una mejora significativa en la performance. Si bien los estándares de Ginga definen que la mayoría de las teclas del control remoto puede ser utilizadas por las aplicaciones NCL/Lua, ésto no siempre es así en los set-top-boxes reales. En el caso de Sokoban, se habían configurado las teclas numéricas del 1 al 7 para elegir el nivel a jugar, pero esta funcionalidad tuvo que ser removida dado que algunos set-top-boxes no permitían usarlas, ya que éstos terminaban cambiando de canal. Por lo tanto se utilizaron dos teclas para el cambio de nivel: una para retroceder al nivel anterior y otra para avanzar al nivel siguiente. 4. Conclusiones El desarrollo de juegos despierta el interés de diferentes actores de la comunicación, y la Televisión Digital no es una excepción. En ocasiones se presenta a los juegos como una herramienta de T-learning. En otras, como una herramienta de inclusión social. Aunque los juegos, al igual que la televisión, son, para una gran mayoría, entretenimiento. Sin importar la finalidad, la plataforma de ejecución es un determinante importante de los juegos que podrían estar disponibles para los televidentes. En la actualidad es posible desarrollar juegos con Ginga NCL/Lua. En estos juegos Lua juega un papel muy importante aunque el gran limitante es la potencia de procesamiento de los equipos receptores. El Sistema Argentino de Televisión Digital Terrestre no es todavía una plataforma madura, al momento de escribir este artículo se están realizando transmisiones de prueba y ajuste. Esperamos que en el futuro junto con la madurez del sistema también se hagan realidad las oportunidades que plantea hacia el sector académico y productivo del desarrollo de juegos. Referencias 1. Flood-It Associação Brasileira de Normas Técnicas. ABNT NBR : GingaNCL para Receptores Fixos e Móveis. 3. Associação Brasileira de Normas Técnicas. ABNT NBR : Espicificação de transmissão de dados. 4. F. Balaguer, A. Alvarez, F. Costa, and L. Woites. Aplicaciones Casuales de Televisión Digital con Ginga NCL/Lua. In Proceedings of the Argentine Simposium of Technology, S. D. J. Barbosa and L. F. Gomes Soares. TV Digital Interativa no Brasil se faz com Ginga. JAI, I. Bogost. Persuasive Games: The Expressive Power of Videogames. The MIT Press, D. Cordeiro Barboza and E. W. Gonzales Clua. Ginga game: A framework for game development for the interactive digital television. In Brazilian Simposium on Games and Digital Entertaintment, 2009.

8 8. Denki. Denki Blocks! 9. R. Ferreira Rodrigues and L. F. Gomes Soares. Produção de Conteúdo Declarativo para TV Digital. 10. L. F. Gomes Soares, R. Ferreira Rodrigues, R. Cerqueira, and S. D. J. Barbosa. Variable Handling in Time-Based XML Declarative Languages. In 2009 ACM Symposium on Applied Computing, L. F. Gomes Soares, R. Ferreira Rodrigues, and M. Ferreira Moreno. Ginga-ncl: the declarative environment of the brazilian digital tv system. In Journal of the Brazilian Computer Society, vol. 12; No. 4, Mars 2007; pp ISSN: , 2007.