Desarrollo de Juegos para Decodificadores SATVD-T Mariana Bernagozzi, Lautaro Woites, Federico Balaguer Lab. de Investigaci´ on y Formaci´ on en Inform´ atica Avanzada Facultad de Inform´ atica - 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´ on de los productores y transmisores de contenidos una nueva tecnolog´ıa que permite transmitir programas de televisi´ on y aplicaciones. Ginga es la especificaci´ on de un middleware que da un ambiente uniforme para el desarrollo de servicios y aplicaciones en un decodificador de TV Digital. Una de las ´ areas de aplicaci´ on 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´ on digital para el desarrollo de juegos.

1.

Introducci´ on

El Sistema Argentino de Televisi´on Digital Terrestre est´a 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´on 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´on Digital Terrestre (SATVD-T) se perfila como una posible plataforma para distribuir juegos consider´andolos como un medio de expresi´on, como son otros contenidos que distribuye la televisi´on [6]. Cordeiro et al presenta la implementaci´on de un Framework Java de juegos como una extensi´on a Ginga [7]. Este trabajo describe la experiencia de desarrollar juegos con otro lenguaje soportado por Ginga: NCL/Lua [2].

2.

M´ odulos del SATVD-T

El Sistema Argentino de Televisi´on Digital Terrestre abarca una gama muy amplia de disciplinas. Las pr´oximas secciones describen tres aspectos importantes para el foco de este trabajo: Creaci´on del Flujo de Transporte, Recepci´on del

Figura 1: Transport Stream

Flujo de Transporte y Ejecuci´on de Aplicaciones NCL/Lua. El flujo de transporte o “Transport Stream” (TS) es una abstracci´on que encapsula todo aquello que se puede transmitir en una frecuencia UHF. 2.1.

Creaci´ on del Flujo de Transporte

El Flujo de Transporte seg´ un la norma ISDB define una estructura en donde existe la posibilidad de transmitir m´as de un programa televisivo en forma simult´ anea. A su vez, cada programa est´a dividido en diferentes servicios: video principal, m´ ultiples 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´on (ISDB-Tb SI) y, por u ´ltimo, los par´ametros de transmisi´on (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´on (Video HD), un canal de audio, y el servicio de teletexto (CC). Generalmente los subcanales est´an definidos alrededor de un Video Principal al cual una aplicaci´on (Ginga) est´a generalmente asociada dentro de un carrousel de datos[9,10,5], pero ´esto no es mandatorio. La norma ISDB-T permite que m´ ultiples aplicaciones viajen en un carrousel. M´as a´ un, un PMT puede contener m´ ultiples 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´ u de un decodificador mostrando varias aplicaciones disponibles. 2.2.

Recepci´ on 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

Figura 2: Men´ u de Aplicaciones Disponibles

estos Flujos de Transporte. De tal manera que en ocasiones cuando el televidente cambia de canal, en realidad el receptor s´olo 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´odulos que comprende un decodificador ISDB-Tb. La secuencia de eventos que ocurren cuando un decodificador recibe un “Transport Stream” se describe a continuaci´on. 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˜ nal tradicional de TV) de los paquetes que representan el Flujo de Datos. El audio y video son procesados y renderizados seg´ un la salida que est´e 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´en 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´an ejecutar. Por ejemplo, receptores basados en chipset ST 7101 cuentan con un procesador de prop´osito general de entre 200 y 300Mhz, procesadores dedicados para renderizar la se˜ nal de televisi´on (audio y video) y una memoria de 256 MBytes. La memoria es compartida entre los m´odulos de decodificaci´on (audio y video), un disco vol´ atil (ram-disk) y memoria vol´atil de trabajo. Al final de cuentas, la memoria de trabajo para Ginga es cercana a los 20 MBytes. Dentro

Figura 3: Esquema del Receptor ISDB-Tb de la familia del chipset ST existen modelos que implementan OpenGL en forma nativa, pero ´estos son para decodificadores de alta gama y mayor costo. 2.3.

Ejecuci´ on de Aplicaciones NCL/Lua

Una aplicaci´on NCL/Lua puede correr en pantalla completa o tambi´en 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´on 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˜ nalizaci´on por medio de eventos que llegan por el Flujo de Transporte (BTS). Los eventos le indican al receptor como debe lanzar la aplicaci´on NCL/Lua. Un posible escenario es cuando el receptor debe lanzar la aplicaci´on de manera inmediata. Otro posible escenario es cuando el receptor debe lanzar la aplicaci´on transcurrido un cierto tiempo asociado con el video principal. Otro posible escenario es cuando el receptor debe esperar que el televidente arranque la aplicaci´on 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´on describe la meta-data del formato XML que sigue el resto del documento. Encabezado del Programa Esta secci´on tiene tres partes: regiones, descriptores de medios y conectores Cuerpo del Programa Esta secci´on describe la relaci´on entre regiones, medias, eventos y los estados que tendr´a la aplicaci´on. La Figura 4 muestra una porci´on de c´odigo NCL que maneja la recepci´on del evento de bot´on rojo. Esta porci´on de c´odigo es parte de las aplicaciones que se presentan en este trabajo en la Secci´on 3.



Figura 4: C´ odigo NCL que define el manejo del bot´on rojo

En la definici´on de un programa NCL, los scripts Lua son tratados como una ´ “Media” m´as. Esto es, es un elemento del programa que puede ser iniciado y detenido. Adem´as, scripts Lua pueden definir funciones como co-rutinas. La norma ISDB-Tb especifica que los scripts Lua tiene acceso a los siguientes m´odulos: 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´aficos. Se definen primitivas de dibujo de elementos geom´etricos simples y texto. Adem´ as los scripts Lua tiene acceso a otros m´odulos definidos en ese lenguaje, el m´as 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]. Este es un juego casual que busca ejercitar el uso de las teclas de color y las teclas de navegaci´on (flechas). Para validar las diferentes partes del middleware, se desarrollaron diferentes tipos de juegos: se hicieron pruebas con juegos de l´ogica similares a Denki Blocks! [8] y Flood-It[1]; y tambi´en 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´aficos, manejo de eventos de teclado (control remoto) y la l´ogica del juego est´an implementados ´ıntegramente en Lua. La aplicaci´on NCL simplemente contiene una media Lua que ocupa toda la pantalla. Para el rendering de gr´aficos se utilizaron primitivas del m´odulo canvas y para el manejo de eventos del control remoto se hizo uso del m´odulo event. Lua, al ser un lenguaje de script y debido a su sencillez, velocidad y tama˜ no, es un lenguaje muy adecuado para codificar la l´ogica de los juegos.

(a) Flood-it!

(b) Snake.

(c) Sokoban.

(d) Tateti.

Figura 5: Capturas de pantalla de los juegos desarrollados.

Sin embargo, el m´odulo canvas es muy limitado, haciendo que sea engorroso el desarrollo de juegos atractivos visualmente. El juego Tateti no est´a desarrollado ´ıntegramente en Lua. La navegaci´on sobre el tablero est´a programada en NCL haciendo uso del atributo focusIndex, links y conectores. El rendering gr´afico se realiza en forma compartida entre NCL y Lua: las medias gr´aficas est´an definidas y ubicadas usando NCL mientras que con Lua se resuelve din´amicamente las im´agenes 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´on sleep dentro del manejador de eventos ya que la misma no permit´ıa que otros eventos sean procesados, por lo que se opt´o por utilizar la funci´on event.timer(ms, f), la cual dispara un temporizador que realizar´a una llamada a la funci´on f luego de ms milisegundos. Una desventaja de la utilizaci´on event.timer es que la funci´on que f no puede recibir par´ametros. 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´o esta misma modalidad para los juegos Sokoban y Tateti, pero como el redibujado de la pantalla es una operaci´on costosa, los juegos no ten´ıan una buena performance

cuando se corr´ıan en un STB. Luego se opt´o por repintar solamente las ´areas de la pantalla que son necesarias en cada turno del juego y se logr´o una mejora significativa en la performance. Si bien los est´andares de Ginga definen que la mayor´ıa de las teclas del control remoto puede ser utilizadas por las aplicaciones NCL/Lua, ´esto no siempre es as´ı en los set-top-boxes reales. En el caso de Sokoban, se hab´ıan configurado las teclas num´ericas 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 ´estos 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´es de diferentes actores de la comunicaci´on, y la Televisi´ on Digital no es una excepci´on. En ocasiones se presenta a los juegos como una herramienta de T-learning. En otras, como una herramienta de inclusi´on social. Aunque los juegos, al igual que la televisi´on, son, para una gran mayor´ıa, entretenimiento. Sin importar la finalidad, la plataforma de ejecuci´on 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´on Digital Terrestre no es todav´ıa una plataforma madura, al momento de escribir este art´ıculo se est´an realizando transmisiones de prueba y ajuste. Esperamos que en el futuro junto con la madurez del sistema tambi´en se hagan realidad las oportunidades que plantea hacia el sector acad´emico y productivo del desarrollo de juegos.

Referencias 1. Flood-It. http://floodit.appspot.com. 2. Associa¸c˜ ao Brasileira de Normas T´ecnicas. ABNT NBR 15606-2: GingaNCL para Receptores Fixos e M´ oveis. 3. Associa¸c˜ ao Brasileira de Normas T´ecnicas. ABNT NBR 15606-3: Espicifica¸c˜ ao de transmiss˜ ao de dados. 4. F. Balaguer, A. Alvarez, F. Costa, and L. Woites. Aplicaciones Casuales de Televisi´ on Digital con Ginga NCL/Lua. In Proceedings of the Argentine Simposium of Technology, 2010. 5. S. D. J. Barbosa and L. F. Gomes Soares. TV Digital Interativa no Brasil se faz com Ginga. JAI, 2008. 6. I. Bogost. Persuasive Games: The Expressive Power of Videogames. The MIT Press, 2007. 7. 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. Denki. Denki Blocks! http://www.denki.co.uk/games/denki-blocks/. 9. R. Ferreira Rodrigues and L. F. Gomes Soares. Produ¸c˜ ao de Conte´ udo 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, 2009. 11. 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. 37-46. ISSN: 01046500, 2007.