Desarrollo de Juegos para Decodificadores SATVD-T

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
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.
2.1.
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.
2.2.
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
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
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.
2.3.
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.
<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.
(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
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. http://floodit.appspot.com.
2. Associação Brasileira de Normas Técnicas. ABNT NBR 15606-2: GingaNCL para
Receptores Fixos e Móveis.
3. Associação Brasileira de Normas Técnicas. ABNT NBR 15606-3: 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, 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çã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, 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.