Protocolo de Aplicação para Jogos de Tabuleiro para Ambiente de TV Digital

Felipe Martins de Lima

Escola de Engenharia – Universidade Federal Fluminense (UFF) Rua Passo da Pátria, 156 – São Domingos – Niterói – RJ – 24210-040 – Brasil

felipemartins@midiacom.uff.br

Resumo. Este artigo propõe uma especificação não-formal para um protocolo de aplicação para jogos de tabuleiro no ambiente de TV Digital. O desenvolvimento do jogo RummiTV pela equipe de jogos do laboratório Mídiacom foi o motivador deste trabalho. Este artigo possui informações iniciais para o desenvolvimento do protocolo e servirá como base para sua implementação futura.

1. Introdução

A TV Digital brasileira ganhou projeção nacional em dezembro de 2007 devido ao início da distribuição do sinal digital para a região metropolitana de São Paulo. Em 2008 outras capitais receberão o sinal, e o objetivo é que até 2016 o sinal digital seja difundido para todo o Brasil [1]. A definição do Sistema Brasileiro de TV Digital - SBTVD, também chamado de nipo-brasileiro por ter sido baseado no padrão para transmissão (modulação) do sistema japonês ISDB, foi realizada pelo governo brasileiro com a contribuição de pesquisadores de diversas universidades brasileiras [2].

Além de fornecer imagem e áudio de excelente qualidade e suportar a exibição em dispositivos móveis e portáteis, a grande inovação se dá pela interatividade. O uso da TV como objeto de inclusão digital é prioridade do governo [1]. Neste contexto, o desenvolvimento de aplicações interativas para TV Digital ocupa lugar de destaque.

O projeto RummiTV, desenvolvido no laboratório Mídiacom da UFF, desenvolveu o jogo eletrônico RummiTV, que é uma adaptação para plataforma de TV Digital Interativa do tradicional jogo de tabuleiro Rummikub [3].

O cenário atual da TV Digital Interativa e o projeto RummiTV são a motivação deste trabalho, que tem por objetivo propor a especificação não-formal de um protocolo de aplicação para jogos de tabuleiro no ambiente de TV Digital. O propósito deste protocolo é

otimizar a comunicação entre clientes e servidores em implementações distribuídas de jogos de tabuleiro para o ambiente de TV Digital.

O trabalho está organizado da seguinte forma. A Seção 2 fala sobre a autoria de aplicações para o sistema brasileiro de TV Digital e a Seção 3 apresenta a atual implementação do jogo RummiTV. A Seção 4 descreve a especificação não-formal do protocolo de aplicação por intermédio de seus métodos principais e na Seção 5 a semântica do protocolo é apresentada por intermédio da descrição da dinâmica do protocolo e do diagrama de estados do lado cliente. O trabalho é concluído na seção 6, que salienta as dificuldades encontradas e faz alguns comentários sobre a próxima versão do protocolo.

2. Autoria de aplicações para o SBTVD

O sistema brasileiro de TV Digital permite o desenvolvimento de aplicações através do uso de dois tipos de linguagens: imperativa e declarativa. As aplicações desenvolvidas para o ambiente de TV Digital, de acordo com a arquitetura em blocos da TV Digital apresentada na figura 1, necessitam de um middleware para processar os dados recebidos e possibilitar a apresentação do conteúdo, independente do hardware ou sistema operacional. Aplicações desenvolvidas em linguagem declarativa necessitam de um middleware declarativo e as aplicações desenvolvidas em linguagem imperativa necessitam de um middleware procedural [4].

Figura 1: Arquitetura em blocos da TV Digital [4].

O middleware do sistema brasileiro foi chamado de Ginga e oferece suporte a aplicações desenvolvidas nas duas abordagens. As aplicações desenvolvidas na abordagem declarativa utilizam o subsistema Ginga-NCL e as aplicações desenvolvidas na abordagem procedural utilizam o subsistema Ginga-J [5]. A arquitetura do middleware Ginga é apresentada na figura 2.

Figura 2: Arquitetura do middleware Ginga [5].

O ambiente declarativo Ginga-NCL utiliza a linguagem NCL (Nested Context Language) como ferramenta de autoria para aplicações declarativas. A linguagem NCL, baseada em XML, é uma linguagem de "cola" que tem como seu foco o sincronismo de mídias e oferece suporte a exibição de conteúdo em múltiplos dispositivos de saída simultâneos, integração de diferentes tipos de objetos de mídia, edição de programação ao vivo, especificação de conteúdo alternativo e integração com objetos que possuem conteúdo procedural, sejam eles Xlets (escritos na linguagem Java) ou NCLua (escritos na linguagem LUA) [6].

Figura 3: Arquitetura do Ginga-NCL [6].

O ambiente procedural Ginga-J utiliza a linguagem Java como ferramenta de autoria para aplicações procedurais. A API Ginga-J é subdividida em três conjuntos chamados de APIs verdes, amarelas e vermelhas, como mostra a figura 4 [7]. As APIs verdes são compatíveis com o núcleo GEM (Globally Executable MHP)[8], ou seja, as aplicações desenvolvidas com estas APIs funcionam em padrões presentes em todo o mundo, como o DVB (Digital Video Broadcasting)[9], o ISDB (Integrated Services Digital Broadcasting Terrestrial) [10] e o ATSC (Advanced Television System Committee)[11]. Nela estão disponíveis, entre outros, os pacotes Sun JavaTV[12], DAVIC[13] e HAVi[14] que estão disponíveis nos outros padrões mundiais de TV Digital. As APIs verdes são responsáveis pela compatibilidade com outros padrões. As APIs amarelas são compatíveis com os outros sistemas de TV Digital através de um adaptador. Nela estão inclusas a API JMF 2.1 (Java Media Framework) necessária para aplicações avançadas como captura de som e vídeo, uma extensão à API de apresentação do GEM para suporte a fluxos de vídeo e outras facilidades. As APIs vermelhas oferecem facilidades para integração de outros dispositivos de entrada e saída ao set-top box e a ponte NCL (NCL Bridge) que permite a integração de conteúdo procedural e declarativo na mesma aplicação. As APIs vermelhas possuem caráter inovador e são exclusivas do SBTVD.

Figura 4: Arquitetura das APIs do Ginga-J [5].

Na próxima Seção são apresentados os componentes do jogo RummiTV e as suas regras de forma resumida. Em seguida, o texto fala da atual implementação do jogo e do problema de desempenho que foi encontrado.

3. RummiTV

O jogo RummiTV é uma versão para o ambiente de TV Digital do jogo Rummikub, desenvolvida em JavaTV. O Rummikub é um dos jogos de tabuleiro mais populares no

mundo, de cunho educativo, cujo objetivo é estimular a capacidade de raciocínio de crianças e jovens acima de 8 anos de idade [3].

O RummiTV possui um conjunto de 106 peças, divididas em 4 cores, sendo 26 amarelas, 26 vermelhas, 26 azuis e 26 pretas, além de 2 coringas. Cada conjunto de peças de uma cor possui duas seqüências numeradas de 1 a 13. No início do jogo, cada jogador deverá receber um conjunto de 14 peças, ficando as demais na mesa. O objetivo é realizar o descarte de todas as peças. O jogo pode ser jogado por no mínimo 2 jogadores e no máximo 4. Para descartar uma peça, um jogador deve possuir um conjunto de no mínimo 3 peças de mesmo número, de cores diferentes, ou 3 peças de números consecutivos da mesma cor, podendo o coringa ser utilizado para substituir uma peça da seqüência. Quem conseguir descartar primeiro todas as suas peças é declarado o vencedor do jogo [3].

Os jogos ficarão a mostra de todos os jogadores. Os jogos podem ser modificados, desde que os jogos continuem válidos, conforme descrito no parágrafo anterior. As operações permitidas são desfazer grupos para formar novas seqüências e vice-versa, dividir jogos para formar outros e substituir um coringa por uma peça e vice-versa. Um jogador, caso não possua peças para descartar (ou não queira descartá-las) deverá receber uma peça das que se encontram na mesa e só poderá jogar novamente na rodada seguinte. Um jogador não pode usar dois coringas no mesmo jogo e para um conjunto de peças do mesmo número não poderá haver peças da mesma cor [3]. Como os jogos ficam a mostra de todos os jogadores, eles devem ser compartilhados entre todos os jogadores de uma partida (clientes) e qualquer modificação realizada durante a jogada de um dos jogadores (um cliente) deve ser enviada para todos os outros participantes da partida (demais clientes). Esta comunicação é feita atualmente usando o paradigma cliente-servidor.

O projeto iniciou com uma implementação do jogo em um ambiente stand-alone com o objetivo de implementar a lógica do jogo e suas funcionalidades principais. A interface desta implementação é mostrada na figura 5.

Figura 5: Interface do jogo RummiTV.

Após estes testes, foi realizada uma implementação em um ambiente distribuído com o objetivo de testar o jogo em um ambiente semelhante ao ambiente de TV Digital. A interface desta implementação é descrita na figura 6. Para efetuar a comunicação entre clientes e o servidor foi utilizada a biblioteca RMI (Remote Method Invocation) nativa do Java e disponível no pacote JavaTV.

Figura 6: Interface do Jogo RummiTV.[3]

O RMI é a implementação da Sun de RPC(Remote Procedure Call) para comunicação distribuída entre objetos Java.[15, 16, 17] Uma vez registrado no lado servidor, um método pode ser procurado e utilizado por um cliente. Toda a comunicação pela rede e toda a serialização dos objetos é realizada pelo RMI e fica transparente para a aplicação. No processo de serialização, o RMI armazena todos os atributos públicos e privados do objeto em um stream para ser enviado pela rede. A sintaxe de chamada de um método remoto é idêntica à da chamada de um método de um objeto local, como é mostrado na figura 7, que trata a transparência como “RMI Magic”. Isso ocorre devido à criação de um objeto proxy local, que na verdade está referenciando um objeto remoto, fazendo com que todo o processo fique transparente para quem chama [16, 17].

Figura 7: O processo de chamada de um método remoto usando RMI [15].

O problema encontrado com a utilização do RMI ocorre justamente por causa do processo de serialização. A necessidade de enviar todo o objeto toda vez que se necessita de alguma informação torna o processo mais lento devido à carga de atributos que muitas vezes não seriam necessários. Por exemplo, imagine um objeto no lado cliente com 10 (dez) atributos. O cliente quer enviar para o servidor apenas 1 (um) desses atributos. A utilização desta implementação envia o objeto com todos os seus atributos.

Devido ao baixo desempenho na comunicação através de RMI, surge a necessidade de especificar e implementar um protocolo de aplicação otimizado para o jogo RummiTV, que é a principal motivação deste trabalho. Na próxima Seção é apresentada uma especificação não-formal de um protocolo de aplicação que será baseado em sockets [18] objetivando ser uma alternativa ao uso do RMI e uma solução ao problema supracitado.

4. Especificação do Protocolo

Esta Seção apresenta a especificação não-formal de um protocolo de aplicação para jogos de tabuleiro no ambiente de TV Digital por intermédio dos métodos do lado cliente e do lado servidor. O objetivo desta seção é identificar os principais métodos que serão utilizados pelas aplicações, porém o desafio é propor métodos genéricos visando fornecer um protocolo que possa ser utilizado por diversos jogos de tabuleiro existentes e não só pelo RummiTV [18].

4.1 - Métodos do lado Cliente

? LOGIN(usuario, senha):

Neste método o usuário se autentica no servidor com um nome de usuário e uma senha previamente cadastrada. Neste momento o cliente está no estado CONECTADO.

? ESCOLHER_JOGO(nome, opção):

Neste método o usuário escolhe dentre os jogos disponíveis qual o jogo que ele deseja jogar. Por exemplo, o usuário pode escolher entre o RummiTV, um jogo de perguntas e respostas ou uma partida de dominó. O parâmetro opção é utilizado para invocar o método ENVIAR_JOGO do lado servidor. Quando o valor do atributo for 0(zero) o cliente já possui a versão mais nova do jogo no seu set-top box [19], mas se o valor for 1(um) o servidor chama o método ENVIAR_JOGO para o cliente receber o pacote Java (xlet) com a última versão do jogo. Neste momento o cliente está no estado AUTENTICADO.

? JOGAR_RODADA(cod_rodada):

Neste método o jogador inicia a sua jogada na rodada especificada. Ao invocar este método, o cliente vai para o estado JOGANDO.

? COMPRAR_PEÇA( ):

Neste método o jogador solicita novas peças ao servidor. Por exemplo, no jogo RummiTV, o jogador que ao final da sua jogada não conseguir formar uma nova seqüência ou trinca, recebe uma carta. Logo a aplicação chama o método para efetuar a compra da carta.

? DESCARTAR_PEÇA(cod_peça):

Neste método o jogador envia para a mesa uma ou mais peças. Por exemplo, em um jogo de perguntas e respostas o jogador que não soubesse responder a uma questão poderia descartar uma peça do tipo "Vale 1 Pulo".

? SAIR_RODADA(cod_rodada):

Neste momento o jogador encerra a sua jogada na rodada especificada. Ao invocar este método, o cliente vai para o estado AGUARDANDO_VEZ.

? SAIR _PARTIDA(cod_partida):

Neste método o jogador abandona a partida do jogo e volta para o estado AUTENTICADO.

? LOGOFF():

Neste método o jogador encerra a sua sessão, finalizando a sua conexão com o servidor e vai para o estado DESCONECTADO.

4.2 - Métodos do lado Servidor

? LOGIN_RESP(cod)

Neste método o servidor responde a requisição de login do cliente. Se usuário estiver cadastrado e a senha estiver correta o servidor responde com o código 200, se a senha estiver incorreta o servidor responde com o código 300. Se o usuário não estiver cadastrado o servidor responde com o código 301.

? LISTAR_JOGOS( );

Este método é solicitado automaticamente sempre que o usuário efetuar login com sucesso e quando o jogador sair de uma partida do jogo. Neste método o servidor envia ao cliente a lista de jogos disponíveis no momento e a versão disponível.

? ENVIAR_JOGO(jogo);

Neste método o servidor responde a requisição do cliente enviando o pacote Java (Xlet) com a última versão do jogo escolhido.

? ESCOLHER_PARTIDA(cod_partida)

Neste método o servidor escolhe qual a partida será disponibilizada para o cliente jogar. Caso não exista nenhuma partida disponível para o jogo escolhido o servidor chama o método CRIAR_PARTIDA(). Caso exista uma partida disponível, a mesma é escolhida para o cliente.

? CRIAR_PARTIDA( )

Este método cria uma nova partida para o jogo solicitado. Este método chama EMBARALHAR_PEÇAS( ).

? EMBARALHAR_PEÇAS(peças)

Este método embaralha as peças necessárias para o início do jogo.

? INICIAR_PARTIDA(cod_partida);

Este método inicia a partida do jogo solicitado. Este método chama os métodos DISTRIBUIR_PEÇAS(cod_peça) e INICIAR_RODADA(cod_rodada, cod_partida, usuario).

? DISTRIBUIR_PEÇAS(peças);

Neste método o servidor distribui para todos os jogadores as peças necessárias para o início da partida.

? INICIAR_RODADA(cod_rodada, cod_partida, usuario);

Neste método o servidor inicia uma nova rodada do jogo. Este método ocorre depois do método DISTRIBUIR_PEÇAS() ou depois do método ENCERRAR_RODADA( ).

? ENCERRAR RODADA(cod_rodada, cod_partida);

Este método é chamado após todos os jogadores concluírem as suas jogadas. No jogo RummiTV, por exemplo, cada jogador tem a sua vez de jogar, mas em um jogo de perguntas e respostas talvez seja interessante que todos os jogadores respondam as perguntas simultaneamente. A aplicação pode ainda atribuir um tempo para que sejam dadas as respostas, e após este tempo chamar o método.

? ENCERRAR_PARTIDA(cod_partida);

Este método encerra a partida especificada.

5. Implementação

A implementação deste protocolo será realizada em Java utilizando a API de sockets para efetuar a troca de mensagens entre os clientes e o servidor. Objetivando auxiliar o desenvolvimento do protocolo propriamente dito será utilizado o diagrama de estados proposto pela linguagem UML (Unified Modeling Language) [20].

O diagrama de estados mostra os diferentes estados de um objeto durante sua vida, e o estímulo que faz com que o objeto mude seu estado. O diagrama de Estado vê os objetos como máquinas de estado que podem ser um de um conjunto de estados finitos e que podem mudar seu estado através de um conjunto finito de estímulos. A figura 8 mostra o diagrama de estados do lado cliente do protocolo.

Figura 8: Diagrama de estados do lado cliente.

6. Conclusões

No contexto atual da TV Digital no Brasil, este trabalho propôs um protocolo de aplicação para jogos de tabuleiro que será desenvolvido em Java utilizando a API de sockets. As idéias desenvolvidas neste trabalho estão alinhadas com o objetivo do governo brasileiro de promover a inclusão digital por intermédio da TV Digital.

O recurso da interatividade presente no SBTVD será de grande importância para diversas áreas da sociedade, tais como comércio, indústria, ensino e entretenimento. Este trabalho tem como objetivo incentivar o desenvolvimento de novos jogos para o ambiente de TV Digital, que podem ter sua comunicação cliente-servidor facilitada fazendo uso do protocolo.

A maior dificuldade no desenvolvimento deste trabalho foi encontrar mensagens genéricas que são trocadas entre clientes e servidor, que possam ser utilizadas pelos mais diversos tipos de jogos de tabuleiro existentes, aumentando desta forma o nível de abstração e as possibilidades de uso do protocolo.

A especificação que foi apresentada utiliza uma seqüência lógica onde o servidor escolhe a qual partida o cliente deverá se conectar, porém já está em fase de estudos uma nova versão onde o cliente terá a possibilidade de criar uma partida em um jogo onde ele será o gestor e concederá as permissões para os outros clientes, ou então ele simplesmente se conectará a uma partida de um jogo já existente.

A especificação apresentada ainda não inclui a comunicação cliente-servidor para realização da jogada, como por exemplo, métodos para atualizar jogos na mesa ou criar novos jogos que utilizem várias peças. A especificação completa do protocolo é colocada como trabalho futuro.

7. Referências

[1] Diário Oficial da União. Decreto-lei 4.901, de 26 de novembro de 2003. Institui o Sistema Brasileiro de Televisão Digital – SBTVD, e dá outras providencias. Diário Oficial da República Federativa do Brasil, Brasília, 27 de nov. 2003. Seção 1, Pág. 7.

[2] ABNT/CEE - COMISSÃO DE ESTUDO ESPECIAL. Projeto 00:001.85-001 Televisão Digital Terrestre - Sistema de Transmissão. ABNT, 2007.

[3] SANTOS, Joel; RATAMERO, Erick. RummiTV - Jogo Eletrônico para TV Digital Interativa. Rio de Janeiro, 2007.

[4] SOARES, L.F.G; RODRIGUES, R.F. Produção de conteúdo declarativo para TV Digital. Seminário Integrado de Software e Hardware, 2006.

[5] Middleware Ginga - TV Interativa se faz com Ginga! http://www.ginga.org.br. Acessado em 29/10/2007.

[6] SOARES, L.F.G.; RODRIGUES, R.F.; MORENO, M.F. Ginga-NCL: The Declarative Environment of the Brazilian Digital TV System. Journal of the Brazilian Computer Society. Porto Alegre, RS, 2007.

[7] SOUZA FILHO, G.L. de; LEITE, L.E.C.; BATISTA, C.E.C.F. Ginga-J: The Procedural Middleware for the Brazilian Digital TV System. Journal of the Brazilian Computer Society. Porto Alegre, RS, 2007.

[8] Globally Executable MHP. http://www.mhp.org/mhp_technology/gem/. Acessado em 02/11/2007.

[9] DVB - Digital Vídeo Broadcasting. http://www.dvb.org. Acessado em 02/11/2007.

[10] Outline of the Specification for ISDB-T - http://www.nhk.or.jp/strl/open99/de-2/shosai-e.html. Acessado em 02/11/2007.

[11] ATSC. http://www.atsc.org. Acessado em 02/11/2007.

[12] Java TV API. http://java.sun.com/products/javatv. Acessado em 02/11/2007.

[13] DAVIC. http://www.davic.org. Acessado em 02/11/2007.

[14] HAVi. http://www.havi.org. Acessado em 02/11/2007.

[15] RMI. http://java.sun.com/javase/technologies/core/basic/rmi/index.jsp. Acessado em 05/11/2007.

[16] SILBERSCHATZ, A.; GALVIN, P.B.; GAGNE, G. Sistemas Operacionais Conceitos e Aplicações. Editora Campus, 2000.

[17] DEITEL, H. M.; DEITEL, P. J. Java: como programar. 4ª Edição. Porto Alegre: Bookman, 2003.

[18] KUROSE, James F.; ROSS, Ketith W. Redes de Computadores e a Internet: uma abordagem top-down. 3ª Edição. São Paulo: Pearson Addisson Wesley, 2006.

[19] Dantas, M.S. Middleware para set-top boxes – Um enfoque prático. Rio de Janeiro: UFF, 2005.

[20] Fundamentos do UML. http://docs.kde.org/stable/pt_BR/kdesdk/umbrello/uml-basics.html. Acessado em 17/12/2007.