serviço tem por finalidade, monitorar a execução da simulação do jogo em busca de eventos relevantes a cada jogador. Quando estes eventos ocorrerem, o serviço utiliza informações de contexto do jogador para enviar mensagens sobre estas ocorrências, de modo que o usuário possa realizar contra medidas a estes eventos. Estas mensagens utilizam diferentes tecnologias de comunicação, como Short Message Service (SMS) ou e-mail, baseadas no dispositivo e preferências pessoais de cada jogador.
O quinto serviço desta camada é o de Integração de Mini-Mundos. Este serviço visa dar suporte ao conceito de Mini-Mundos do modelo de aplicação PM2G. De forma sucinta, o serviço tem como principais funções (i) permitir que informações do perfil do personagem de um jogador, como armas, níveis de força ou magia possam ser migradas entre o mundo virtual simulado e os jogos paralelos que representam mini-mundos e (ii) bem como permitir que os resultados decorrentes destas partidas paralelas possam ser posteriormente integrados com o jogo e usadas no mundo virtual simulado.
Os serviços anteriormente descritos foram concebidos de modo a tratar questões específicas do domínio da aplicação-alvo, no caso, as aplicações PM2G. Seguindo a abordagem de cama- das de middleware, estes serviços são colocados acima de serviços já existentes, relacionados tanto com plataformas de middleware para computação pervasiva, quanto para jogos multiu- suário (Vide Figura 6.2). Esta disposição indica que a arquitetura busca reusar estes serviços, como por exemplo, a utilização de um serviço de localização adequado a uma aplicação PM2G, como o Location Inference Service (LIS) de MoCA [SER+04].
No último bloco da arquitetura, o cliente PM2G representa a aplicação de acesso do jogador ao jogo. Esta aplicação recebe e envia informações tanto aos serviços quanto ao jogo, por meio de uma API. Ressalta-se que, embora não ilustrado no diagrama, o cliente também teria acesso às APIs das demais plataformas de middleware, que sejam integradas ao jogo, como MoCA [SER+04].
6.3
Framework de Comunicação PM2G
Como ressaltado na Seção 6.2, a arquitetura de serviços PM2G utiliza o modelo cliente/servidor para possibilitar o compartilhamento do estado do jogo entre jogadores. Nesta arquitetura, procurou-se uma forma de padronizar a comunicação entre jogadores e o servidor do jogo. Assim sendo, o fluxo de comunicação segue um modelo simplificado para aplicações de espaço compartilhado, apresentado na Figura 6.3.
6.3 FRAMEWORK DE COMUNICAÇÃO PM2G 85
Figura 6.3 Fluxo de Comunicação Cliente/Servidor, adaptado de [BBV03]
com a interação do usuário com a interface do jogo. Estes eventos são então repassados ao servidor do jogo. O servidor lê, realiza o parsing das mensagens recebidas e repassa cada evento ao framework de simulação. A simulação também é responsável pela geração de novos eventos, de acordo com a lógica do jogo, de forma independente das ações dos clientes. A partir da simulação, o estado do jogo é então repassado a cada jogador, de acordo com sua área de interesse. O cliente recebe esta informação, que então a apresenta ao usuário. A partir desta representação, o ciclo se repete.
Uma vantagem nesta abordagem para a proposta PM2G é que procura-se evitar (i) proces- samentos locais custosos nos dispositivos, (ii) a necessidade de uma constante comunicação para repasse dos eventos, bem como (iii) a necessidade de procedimentos mais complexos de sincronização entre clientes e o servidor. Em suma, os clientes atuam como interfaces de apre- sentação e interação com o servidor, sem processamento do estado do jogo localmente. Todo processamento relativo à simulação do mundo virtual é de responsabilidade do servidor. Em contrapartida, a quantidade de informações que representa o estado do jogo tende a ser maior que o repasse do conjunto de eventos enviados pelos jogadores. Em nossa proposta este pro- blema é atenuado, pois o mundo virtual é dividido em áreas de interesse, e o jogador só recebe informações sobre a área com que interage em um dado instante.
Baseado nesta idéia, o framework de comunicação foi elaborado como uma adaptação da proposta de Bracken el al[BBV03]. Em sua proposta original, a comunicação utiliza a abor-
6.3 FRAMEWORK DE COMUNICAÇÃO PM2G 86
dagem de retransmissão dos eventos pelo servidor apenas para clientes que utilizem computa- dores pessoais. Nossa adaptação modificou este framework para que eventos sejam enviados apenas pelos jogadores (independente se estes utilizam PCs ou dispositivos móveis), enquanto o servidor repassa aos jogadores o estado completo da simulação.
Outro aspecto importante é que na proposta PM2G, toda a comunicação entre clientes e o jogo é encapsulada na forma de eventos de jogo (Game Event). Toda mensagem transmitida pelos clientes é transformada pelo framework de comunicação para um formato padronizado, antes de ser repassado ao framework de simulação. Este formato é representado pela Figura 6.4.
Figura 6.4 Representação em UML de um Evento do Jogo – GameEvent.
Cada evento é gerado por um jogador (playerId), e possui um tipo que o identifica dentro do protocolo de comunicação com o servidor, e também com a simulação (eventType). Embora o formato de dados relacionado com cada evento seja dependente do projeto de cada jogo, o mesmo deve ser transparente para o framework, uma vez que é disponibilizada esta interface para eventos e seu tratamento pelo servidor. Cada jogo pode ter seu formato distinto. Para isto, cada evento utiliza uma lista de conteúdo que guarda o conteúdo de cada mensagem transmitida entre jogadores e o servidor, e vice-versa. Por exemplo, o evento relativo à movimentação do avatar do jogador encapsula as novas coordenadas do mundo virtual para onde o mesmo queira se deslocar.
6.3.1 Arquitetura
A Figura 6.5 apresenta uma versão simplificada da arquitetura do framework de comunicação PM2G. A classe GameServer representa o servidor do jogo. Este tem a função de aceitar as conexões dos clientes, gerenciar conexões ativas de jogadores em computadores pessoais, gerenciar a classe responsável pelo jogo em si, chamada GameController. O servidor lida com todo o processo marshaling e unmarshaling de mensagens transmitidas entre jogadores e o servidor do jogo, criando uma transparência no processo de comunicação.
A estrutura de comunicação do Servidor possui duas classes auxiliares: SelectAndRead e EventWriter. A primeira classe é responsável pelo processamento da mensagem recebida pelo servidor, sua transformação em um evento do jogo (GameEvent), e repasse ao GameController.