Serviço de Notificação de Mensagens

O Serviço de Notificação de Mensagens tem a função de informar aos jogadores sobre acon- tecimentos de seu interesse, principalmente quando estes jogadores estiverem em um contexto móvel. Este serviço é o principal responsável por criar a idéia do jogador móvel estar sempre conectado ao jogo. A idéia é permitir que o jogador esteja sempre presente, sendo notificado através de diferentes meios de comunicação, como mensagens Short Message Service (SMS) ou e-mails.

No contexto estacionário, o jogador tem acesso direto ao mundo e seus eventos de interesse acontecem mediante sua presença, não fazendo sentido a emissão de notificações. O serviço de notificação de mensagens cria uma abstração para que jogadores móveis possam ser alertados sobre diferentes eventos relativos tanto em relação a eventos de sua área de interesse do mundo virtual, quanto a situações de seu mundo real, como desafios para partidas formadas por mini- mundos.

No mundo virtual, eventos representam acontecimentos relativos ao personagem do joga- dor, ao seu clã, ou qualquer outro elemento do jogo cuja alteração de estado seja de interesse do jogador. O comportamento assíncrono dos jogadores móveis indica que durante a execução de suas ações, seu personagem do jogador estará sujeito a influências de elementos de sua área de interesse, como ataque de outros jogadores. Este serviço surge com canal natural de aviso da execução e das possíveis interferências sofridas por estes comandos.

6.5 SERVIÇOS DE MIDDLEWARE PARA JOGOS PM2G 113

ficação de Eventos pode alertar a presença de objetos virtuais que estiverem situados próximos à localização física de um jogador, de acordo com seu deslocamento e estado. De forma se- melhante, o serviço pode alertar o jogador a respeito de mini-mundos ou jogadores a serem desafiados em suas cercanias.

6.5.4.1 Modelagem

Em sua concepção, procurou-se criar a idéia de um serviço genérico, onde um evento pode ser disparado de qualquer outro componente da arquitetura que queira se utilizar do serviço para enviar mensagens para um jogador. Cada evento deve ser repassado ao serviço, que uma vez recebido, deve tomar as seguintes medidas:

1. identificar o jogador relacionado ao evento;

2. identificar o tipo do evento a ser informado ao jogador;

3. criar uma mensagem relativa ao evento, baseado no contexto atual do jogador, e; 4. enviar a mensagem ao jogador.

Nesta concepção, um evento, representado pela classe PM2GEvent da Figura 6.30, é sem- pre associado a um jogador. Esta classe representa qualquer evento, quer ser seja ele oriundo de eventos da simulação ou do mundo real do usuário. Porém, diferentes tipos de eventos podem inserir informações específicas. Por exemplo, se o desenvolvedor quer notificar um jogador que seu avatar está sendo atacado por outro jogador, é importante incluir a informação sobre este adversário. Sendo assim, cabe ao desenvolvedor, criar novos tipos de eventos como espe- cializações de um evento convencional. Em outras palavras, um desenvolvedor deve estender a classe PM2GEvent, para criar novos eventos.

Uma vez que cada evento possui informações específicas, deve haver um mecanismo que trate cada evento individualmente. O tratamento de um evento pelo serviço refere-se à criação e envio de uma mensagem ao usuário, de acordo com o contexto deste jogador. Para viabilizar esta concepção, cada evento deve possuir um procedimento que forneça mensagens relativas ao evento, nas diferentes tecnologias de comunicação suportadas pelo jogo. De uma forma genérica, esta visão é representada pela classe abstrata MessageFactory da Figura 6.30, que a partir de um evento e do atual contexto do jogador, é capaz de criar mensagens em diferentes tecnologias de comunicação.

Toda mensagem (classe Message) possui um conteúdo (atributo content), que representa o texto a ser repassado ao jogador. Porém, diferentes tecnologias possuem atributos extras e

6.5 SERVIÇOS DE MIDDLEWARE PARA JOGOS PM2G 114

Figura 6.30 Diagrama de Classes – Evento PM2G e Criadores de Mensagens.

limitações específicas para a criação deste texto. Como exemplo, mensagens SMS possuem fortes limitações sobre o tamanho da mensagem a ser enviada. Além disso, cada evento utili- zará dados particulares para criação da mensagem. Sendo assim, cada evento específico deverá especificar os passos necessários para a criação das mensagens em cada tecnologia. Com isto, cada classe que realize o tratamento de um evento, deve então estender a classe MessageFac- tory, fornecendo operações para a criação de mensagens nas diferentes tecnologias suportadas pelo jogo.

Uma vez criadas as mensagens, o serviço então envia a mensagem para o usuário, de acordo com o contexto do jogador. Diferentes alternativas de envio de mensagens possuem seus emis- sores, como email ou SMS. Estes recebem uma mensagem e a enviam ao jogador. Cada emissor segue a especificação da interface MessageSender, representada na Figura 6.31.

6.5.4.2 Arquitetura Interna

A Figura 6.32 apresenta a arquitetura proposta para o Serviço de Notificação de Mensagens como um diagrama de classes em UML.

Componentes e elementos externos à arquitetura que queiram enviar eventos ao serviço, utilizam uma instância da classe EventSender. Esta classe possui um método processEvent, que recebe um evento, e o coloca em uma fila para ser tratado pelo serviço. A única operação

6.5 SERVIÇOS DE MIDDLEWARE PARA JOGOS PM2G 115

Figura 6.31 Diagrama de Classes – Emissores de Mensagens.

Figura 6.32 Diagrama de Classes – Arquitetura Interna do Serviço de Notificação de Mensagens

ofertada pelo serviço é representada pela interface IEventManager, através de seu método pu- blish, que recebe um evento enviado por outro componente da arquitetura. O serviço possui um gerenciador (EventManager), que ao receber este evento, descobre qual é a classe de trata- mento associada ao evento. Esta relação é determinada através de um arquivo de configuração, cuja estrutura é apresentada na Figura 6.33, onde estão definidos os mapeamentos entre eventos e seus respectivos procedimentos de tratamento.

A Figura 6.34 apresenta os passos seguidos pela execução do serviço. A simulação do jogo ou algum serviço interessado em enviar mensagens a um jogador, cria o evento e utiliza a classe EventSender para enviá-lo ao Gerenciador de Eventos (EventManager). Nesta classe é mantida uma estrutura que mapeia em memória as relações estabelecidas no arquivo de configuração descrito previamente. Um vez recebido um evento do jogo, o gerenciador recupera a classe que irá tratá-lo. Esta classe constrói a mensagem de acordo com o evento e o atual contexto do jogador. Uma vez criada a mensagem, esta é repassada ao Gerenciador de Mensagens (MessageManager). Este componente possui referências a todos os emissores de mensagens

6.5 SERVIÇOS DE MIDDLEWARE PARA JOGOS PM2G 116 <?xml version="1.0" encoding="ISO-8859-1"?> <event_manager> <event_conf> <event_class>Class1Name</event_class> <message_factory_class>Class1ObjectFactory</message_factory_class> </event_conf> <event_conf> <event_class>Class2Name</event_class> <message_factory_class>Class2ObjectFactory</message_factory_class> </event_conf> ... <event_conf> <event_class>ClassNName</event_class> <message_factory_class>ClassNObjectFactory</message_factory_class> </event_conf> </event_manager>

Figura 6.33 Configuração entre Eventos e ObjectFactories.

(MessageSender), que enviam mensagens de acordo com tecnologias específicas. A partir da mensagem recebida, o gerenciador utiliza então o emissor específico para enviar a mensagem ao jogador.

6.5 SERVIÇOS DE MIDDLEWARE PARA JOGOS PM2G 117