Protocolo de Aplicação para Jogos de Tabuleiro - Midiacom

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
[email protected]
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 nipobrasileiro 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/shosaie.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/umlbasics.html. Acessado em 17/12/2007.