UNIVERSIDADEFEDERALDOCEARÁ CENTRODETECNOLOGIA ...

UNIVERSIDADE FEDERAL DO CEARÁ

CENTRO DE TECNOLOGIA

DEPARTAMENTO DE ENGENHARIA DE TELEINFORMÁTICA

PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA DETELEINFORMÁTICA

Vanessa Viana da Silva Carvalho

Geração de Jogos Multiníveis e com Múltiplos Usuários por meio de Modelagemem Redes de Petri Coloridas Hierárquicas

FORTALEZA - CEARÁ

2014

Vanessa Viana da Silva Carvalho

Geração de Jogos Multiníveis e com Múltiplos Usuários por meio de Modelagem em Redes dePetri Coloridas Hierárquicas

Dissertação de Mestrado apresentada à Co-ordenação do Programa de Pós-Graduaçãoem Engenharia de Teleinformática da Uni-versidade Federal do Ceará como parte dosrequisitos para obtenção do grau de Mestreem Engenharia de Teleinformática. Área deConcentração: Sinais e Sistemas

Orientador: Prof. Dr. José Marques Soares

FORTALEZA - CEARÁ

2014

Dados Internacionais de Catalogação na Publicação

Universidade Federal do Ceará

Biblioteca de Ciências e Tecnologia

C329g Carvalho, Vanessa Viana da Silva.

Geração de jogos multiníveis e com múltiplos usuários por meio de modelagem em redes de

petri coloridas hierárquicas / Vanessa Viana da Silva Carvalho. – 2014.

94 f. : il. color., enc. ; 30 cm.

Dissertação (Mestrado) – Universidade Federal do Ceará, Centro de Tecnologia, Departamento

de Engenharia de Teleinformática, Programa de Pós-Graduação em Engenharia de

Teleinformática, Fortaleza, 2014.

Área de Concentração: Sinais e Sistemas.

Orientação: Prof. Dr. José Marques Soares.

1. Jogos eletrônicos. 2. Teleinformática. 3. Modelagem computacional. I. Título.

CDD 621.38

Dedico este trabalho à minha família que tanto amo.

Agradecimentos

Primeiramente agradeço a Deus por existir e à N. S. de Fátima por continuarexistindo.

À minha mãe, Áurea Viana, que sem ela eu não teria conquistado nada. A ela devotudo o que sou nesta vida.

Ao meu esposo e melhor amigo, Edigleison Carvalho, o amor da minha vida, minharazão por querer sempre continuar e nunca desistir.

À minha irmã, Thaís Jordana, e seu esposo, Nildo Loiola Dias, que sempre meapoiaram em todos os momentos. A eles sou eternamente grata.

Ao meu grande amigo Paulo Artur, que nunca negou em revisar meus textos esempre esteve disponível em todos os momentos difíceis e alegres da graduação ao mestrado.

Ao meu amigo que me acompanhou nas disciplinas do mestrado, Diego AguiarSousa. Aos amigos que me acompanham desde a graduação, Rodrigo Teles e Danilo Leal.Aos meus amigos que frequentam o Departamento de Física que sempre me acompanharamnas refeições no Restaurante Universitário. Aos meus amigos de longa data de colégio(C7S) e todos meus amigos que entendem minha ausência e sempre torcem pelo meusucesso.

À Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (CAPES), porfornecer fundos para realização da minha pesquisa.

Aos departamentos de Física e de Engenharia de Teleinformática (DETI) da UFC,por por fornecerem espaço físico e equipamentos para realização do meu trabalho

Aos alunos Joel Cruz Soares e Felipe Mota Barreto, pela relação amigável, mútuae vantajosa neste projeto.

Por fim, meu agradecimento em especial ao meu orientador, prof. Dr. José MarquesSoares, e aos professores Dr. Giovanni Cordeiro Barroso e MSc. Carlos Hairon R. Gonçalvespor toda paciência, dedicação e ensinamentos durante o período do meu mestrado.

“A noble spirit embiggens the smallest man”(Jebediah Springfield)

ResumoEste trabalho apresenta um método para geração de jogos multiníveis e com múltiplosusuários por meio de modelagem em Redes de Petri Coloridas Hierárquicas. A concepçãode um jogo multiusuário, contendo múltiplos ambientes de navegação (multiníveis), é feitaa partir da criação de um modelo hierárquico em Rede de Petri Colorida, no qual seespecificam todas as regras, propriedades e estruturas do jogo. O modelo criado para o jogopode ser analisado formalmente, verificando-se, por exemplo, a existência de bloqueios ede transições mortas (caminhos inválidos), entre outros possíveis problemas de concepção,o que pode ser feito com a utilização de ferramentas disponíveis no CPN Tools. Paravalidar esse método, foi concebida uma ferramenta, denominada CPN Games, que permiteo desenvolvimento rápido e dinâmico de jogos de concepção simples exclusivamente porRede de Petri Colorida Hierárquica. Os códigos em XML de modelos constituídos como CPN Tools são interpretadas pelo CPN Games seguindo um conjunto de regras pré-estabelecidas para instanciar diferentes jogos, sem a necessidade de programação adicional.São demonstrados os mecanismos de criação, análise e validação dos modelos e diferentesexemplos de jogos construídos com a ferramenta.

Palavras-chaves: redes de petri coloridas hierárquicas. modelagem formal. geração auto-mática de jogos. jogos eletrônicos. jogos de concepção simples. cpn tools.

AbstractThis work presents a method to generate games with multilevel and multiple users usingHierarchical Coloured Petri Nets. The design of a multiuser game containing multiplenavigation environments (multilevel) is made from the model of a Hierarchical ColouredPetri Net, in which are specified all of the rules, properties and structures of the game. Thecreated model for the game can be formally analysed, verifying the existence of deadlocksand invalid paths, for example, and others possible conception problems, that can bedone with the tools available on CPN Tools. To validate this method, a tool has beendeveloped, called CPN Games, which allows fast and dynamic development of simpleconception games only using Hierarchical Coloured Petri Nets. The XML codes of thedesigned models in CPN Tools are interpreted by CPN Games following a set of predefinedrules to instantiate different games, without additional programing. It is demonstrated themechanisms of the design, analysis and validation of the models and finally it is presentedseveral examples of games developed by this tool.

Key-words: hierarchical coloured petri nets. formal modelling. automatic game generation.electronic games. simple conception games. cpn tools.

Lista de ilustrações

Figura 1 – Ilustração de uma RP. . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Figura 2 – Representação do disparo da transição t1. . . . . . . . . . . . . . . . . 19Figura 3 – Representação de uma RPC. . . . . . . . . . . . . . . . . . . . . . . . . 22Figura 4 – Marcação de um lugar com duas fichas do tipo STRING. . . . . . . . . 22Figura 5 – Exemplo do grafo do espaço de estados da RPC da Figura 4 gerado na

ferramenta CPN Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Figura 6 – Modelagem didática de uma RPC. . . . . . . . . . . . . . . . . . . . . 28Figura 7 – Planet Tour gerado a partir da rede apresentada na Figura 6. . . . . . 28Figura 8 – Modificação da rede da Figura 6 para permitir o movimento de perso-

nagens da direita para a esquerda no jogo Planet Tour. . . . . . . . . . 29Figura 9 – Personagem voltando ao estado inicial do jogo. . . . . . . . . . . . . . 29Figura 10 – Modelagem do jogo Planet Tour em uma Rede de Petri Colorida Hie-

rárquica. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Figura 11 – Sub-rede t5 da transição t5 da rede da Figura 10. . . . . . . . . . . . . 31Figura 12 – Sub-rede t9 da transição t9 da rede da Figura 11. . . . . . . . . . . . . 31Figura 13 – Palheta para o cálculo do Espaço de Estados na ferramenta CPN Tools. 32Figura 14 – Mensagens do resultado dos cálculos realizados pela ferramenta CPN

Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Figura 15 – Passos para a geração do grafo do espaço de estados . . . . . . . . . . 33Figura 16 – Passos para a geração do grafo do espaço de estados . . . . . . . . . . 33Figura 17 – Rede da Figura 10 sem a transição t1. . . . . . . . . . . . . . . . . . . 34Figura 18 – Relatório gerado pela ferramenta CPN Tools a partir da rede da Figura

17. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Figura 19 – Gráfico do State Space gerado pela ferramenta CPN Tools a partir da

rede da Figura 17. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Figura 20 – Identificação de lugares, transições e arcos em um arquivo .cpn. . . . . 38Figura 21 – Início do XML de uma transição hierárquica. . . . . . . . . . . . . . . 39Figura 22 – Exemplo de um arquivo que define as propriedades gráficas e sonoras

do jogo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Figura 23 – À direita, o jogo gerado a partir da rede da Figura 10, apresentada à

esquerda. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Figura 24 – Personagens em dois níveis diferentes do game, baseado nas sub-redes

das Figuras 11 e 12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Figura 25 – Rede da Figura 10 sem o lugar planet3. . . . . . . . . . . . . . . . . . . 42Figura 26 – Geração do jogo Planet Tour relativo à rede da Figura 25. . . . . . . . 43Figura 27 – Rede da Figura 10 com o lugar planet9. . . . . . . . . . . . . . . . . . 43

Figura 28 – CPN Games apresentando a geração do game relativo à rede da Figura27. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Figura 29 – Jogo gerado a partir da RPC da Figura 10. . . . . . . . . . . . . . . . 44Figura 30 – Jogo gerado a partir da rede da Figura 25. . . . . . . . . . . . . . . . . 45Figura 31 – Nível inicial da RPC Hierárquica modelada para o jogo. . . . . . . . . 46Figura 32 – Modelagem da transição de substituição trTema1 da rede apresentada

na Figura 31. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Figura 33 – Modelagem da transição de substituição trTema2 da rede apresentada

na Figura 31. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Figura 34 – Imagem do jogo resultante da modelagem da rede apresentada na Figura

31. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Figura 35 – Imagem do jogo relativo à rede da Figura 32. . . . . . . . . . . . . . . 47Figura 36 – Exemplo de Jogo modelado em RPC. . . . . . . . . . . . . . . . . . . . 49Figura 37 – Evolução da RPC apresentada na Figura 36 e o jogo de concepção

simples gerado à partir desta. . . . . . . . . . . . . . . . . . . . . . . . 50Figura 38 – Configuração das propriedades de um player no jogo (.properties). . . . 51Figura 39 – Configuração das propriedades dos locais do jogo. . . . . . . . . . . . . 52Figura 40 – Configuração das propriedades dos objetos. . . . . . . . . . . . . . . . . 53Figura 41 – Modelagem da vizinhança em RPC. . . . . . . . . . . . . . . . . . . . . 54Figura 42 – Modelagem da Casa1. . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Figura 43 – Exemplo da modelagem de um jogo. . . . . . . . . . . . . . . . . . . . 55Figura 44 – Configuração da política NPC para o jogo da Figura 43. . . . . . . . . 55Figura 45 – Sequência de políticas de NPC para comportamentos complexos. . . . . 56Figura 46 – Relatório de análise da RPC apresentada na Figura 41. . . . . . . . . . 56Figura 47 – Espaço de estados da rede apresentada na Figura 41. . . . . . . . . . . 57Figura 48 – Relatório gerado pelo CPN Tools a partir da rede apresentada na Figura

43. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Figura 49 – Espaço de estados da rede apresentada na Figura 43. . . . . . . . . . . 57

Lista de tabelas

Tabela 1 – Regras para criação de fichas representativas de personagem. . . . . . . 49

Lista de abreviaturas e siglas

CPN Coloured Petri Net

EE Espaço de Estados

NPC Non-Player Character

RP Rede de Petri

RPC Rede de Petri Colorida

Sumário

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2 FUNDAMENTAÇÃO TEÓRICA E TRABALHOS RELACIONADOS 172.1 Redes de Petri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.1.1 Definição formal de uma RP . . . . . . . . . . . . . . . . . . . . . . . . . 182.1.2 Comportamento dinâmico das RPs . . . . . . . . . . . . . . . . . . . . . . 192.1.3 Propriedades e Métodos de Análise de RPs . . . . . . . . . . . . . . . . . 192.2 Redes de Petri Coloridas . . . . . . . . . . . . . . . . . . . . . . . . . 202.2.1 Estrutura principal de uma Rede de Petri Colorida . . . . . . . . . . . . . . 212.2.2 Comportamento dinâmico das RPCs . . . . . . . . . . . . . . . . . . . . . 222.2.3 Geração do Espaço de Estados com o CPN Tools . . . . . . . . . . . . . . 232.2.4 Temporização em RPCs . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.3 Trabalhos relacionados a jogos usando Redes de Petri . . . . . . . . 24

3 MODELAGEM DE JOGOS DE CONCEPÇÃO SIMPLES COM RE-DES DE PETRI COLORIDAS . . . . . . . . . . . . . . . . . . . . . 27

3.1 Os elementos do jogo e a movimentação de personagens . . . . . . 273.2 Representação de múltiplos níveis . . . . . . . . . . . . . . . . . . . . 303.3 Simulação e análise através do modelo RPC . . . . . . . . . . . . . . 313.4 Interpretação da Codificação de um modelo em RPC . . . . . . . . . 373.5 Representação gráfica dos elementos do modelo RPC . . . . . . . . 393.6 Exemplo do Jogo Gerado a partir do Modelo em RPC . . . . . . . . 403.7 Efeitos de modificação no modelo em RPC . . . . . . . . . . . . . . 423.8 Implementação da interação com o usuário . . . . . . . . . . . . . . 423.9 Execução em rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.10 CPN Quiz: um Jogo Educativo de Perguntas e Respostas . . . . . . 453.11 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4 CONFIGURAÇÕES AVANÇADAS NO CPN GAMES . . . . . . . . 484.1 Configurações avançadas . . . . . . . . . . . . . . . . . . . . . . . . . 484.1.1 Uso de cores estruturadas e representatividade dos campos de uma ficha . . 494.1.2 Configuração gráfica de Personagens, Lugares e Objetos . . . . . . . . . . 514.1.3 Criação de Fases ou Mundos do Jogo . . . . . . . . . . . . . . . . . . . . 534.2 Configuração de NPC . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.3 Análises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.4 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5 CONCLUSÕES E TRABALHOS FUTUROS . . . . . . . . . . . . . 59

Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

APÊNDICES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

APÊNDICE A – RELATÓRIO - FIGURA 18 . . . . . . . . . . . . . 64

APÊNDICE B – RELATÓRIO - FIGURA 46 . . . . . . . . . . . . . 67

APÊNDICE C – RELATÓRIO - FIGURA 48 . . . . . . . . . . . . . 70

ANEXOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

ANEXO A – ARTIGO - SBGAMES 2014 . . . . . . . . . . . . . . . 74

ANEXO B – ARTIGO - SBIE 2014 . . . . . . . . . . . . . . . . . . 79

ANEXO C – ARTIGO - EPOCA 2014 . . . . . . . . . . . . . . . . 85

15

1 Introdução

As dificuldades inerentes ao projeto de um jogo eletrônico são as mesmas que vêmsendo debatidas no contexto da Engenharia de Software desde o início da década de 1970.Alguns dos problemas especialmente encontrados no desenvolvimento deste tipo particularde software são discutidos em (PETRILLO et al., 2009).

Segundo (BLOW, 2004), o desenvolvimento de jogos mudou bastante desde adécada de 90, tendo evoluído de uma atividade divertida para algo complexo e de difícilimplementação. Para exemplificar, (BLOW, 2004) mostra um exemplo de número crescentede componentes no desenvolvimento de um jogo, na data de publicação do artigo (2004),em relação ao desenvolvimento em 1994. Hamann1 [2003] coloca em perspectiva umacaracterística particular à indústria de jogos eletrônicos, que é o grande volume dependências existentes quando se está próximo ao final do projeto - deadline - (que oautor chama de Crunch Time), e também afirma que esse tipo de problema não é exclusivode desenvolvimento de jogos. Contudo, (GERSHENFELD; LOPARCO; BARAJAS, 2007)afirma que este problema não é uma característica totalmente danosa, uma vez que algunsdesenvolvedores produzem mais quando estão em situação de estresse.

Outro problema relatado é a rápida obsolescência devido à alta reciclagem dastecnologias de vanguarda. A instabilidade das novas tecnologias, bem como a falta depessoas que as dominam agrava o problema (PETRILLO et al., 2009). Infere-se que seos projetistas de jogos escolhessem usar uma ferramenta especializada para a criação dejogos, haveria uma queda no número de problemas encontrados.

Por outro lado, existem muitas ferramentas próprias para o desenvolvimento dejogos, porém elas não possuem todos os elementos que um projetista necessita para gerarum jogo (BLOW, 2004). Em geral, elas são demoradas para compilar, depurar e testar.Por essa razão, muitos elementos necessários em um jogo têm que ser desenvolvidos dozero (from scratch). Então, é entendido que a construção de ferramentas que auxiliam odesenvolvimento de jogos é uma área aberta a novos estudos.

Uma área em que os jogos estão tomando destaque é na educação. Os jogoseducativos vêm sendo progressivamente incluídos no processo da educação (PRENSKY,2005), (HWANG; WU, 2012). Um exemplo pode ser visto em uma entrevista cedida ao TheAtlanta Journal-Constitution2 em 2012, na qual Bill Gates afirma que os jogos eletrônicoseducativos podem ser um complemento da educação tradicional. A fundação de Gates -1 Hamann, W.; "Goodbye postmortems, hello critical stage analysis", 2003. <http://www.gamasutra.

com/view/feature/131235/goodbye_postmortems_hello_.php>2 <http://www.ajc.com/news/news/opinion/game-based-learning/nQXGw/>

http://www.gamasutra.com/view/feature/131235/goodbye_postmortems_hello_.php

http://www.gamasutra.com/view/feature/131235/goodbye_postmortems_hello_.php

http://www.ajc.com/news/news/opinion/game-based-learning/nQXGw/

Capítulo 1. Introdução 16

Bill Melinda & Gates Foundation3 - é propositora de financiamento para projetos nessedomínio.

Existe uma grande variedade de jogos educativos desenvolvidos para aplicaçõesem diversas áreas. Um exemplo financiado pela Bill & Melinda Gates Foundation é ojogo Refraction4. Nesse exemplo, o usuário adquire o aprendizado com a supervisão doprofessor, que pode acompanhar passo-a-passo a evolução do aluno no jogo. Além dosexemplos financiados pela fundação de Gates, existem diversos outros exemplos de jogosdessa natureza, tais como (BARBOSA et al., 2008), (GRÜBEL; BEZ, 2006), (MANN etal., 2002), (VECCHIA; MALTEMPI; WEINGARTEN, 2014) e (PIETRUCHINSKI et al.,2011).

Como contribuição para a área de jogos, neste trabalho é apresentado um métodode construção de jogos de concepção simples usando modelos em Redes de Petri ColoridasHierárquicas. Neste trabalho é usado o termo "jogos de concepção simples"à jogos deinterfaces bidimensionais, com nós posicionados em grade e que se ligam apenas comelementos vizinhos ou elementos posicionados na diagonal. Para a validação do método, édemonstrada uma ferramenta que fornece ao projetista um ambiente em que é possívelcriar novos jogos multiníveis e multiusuários por meio de modelagem. O arquivo de códigode uma Rede de Petri Colorida (RPC) é processado e é gerada uma instância de umjogo, sem qualquer codificação após a criação do modelo. Os locais, caminhos e regrassão estabelecidos no jogo por meio de uma RPC, a qual é modelada usando a ferramentaCPN Tools5. O código XML de uma RPC, que é modelada pelo CPN Tools, é interpretadapor uma aplicação em Java que constrói a interface gráfica do jogo para o usuário. Ainteração do usuário com a interface gráfica é feita conforme regras estabelecidas durantea modelagem usando os formalismos da RPC. Além da possibilidade da representaçãoformal dos aspectos estáticos e dinâmicos de um jogo, a RPC permite a verificação e avalidação dos modelos projetados, usando ferramentas de análises e simulação disponíveisno CPN Tools.

Este trabalho está estruturado da seguinte maneira: no Capítulo 2, é apresentadoo elemento teórico que compõe o estudo deste trabalho, as Redes de Petri (RP). Algunstrabalhos relacionados também são apresentados nesse capítulo. No Capítulo 3, sãodiscutidas as regras de modelagem e análise para geração de jogos por meio de RPCs e arelação com o jogo de validação, Planet Tour. No Capítulo 4, são apresentadas configuraçõesmais complexas para a interpretação da rede pela ferramenta de validação, CPN Games.No Capítulo 5, são apresentadas as conclusões e os trabalhos futuros.

3 <http://www.gatesfoundation.org/>4 <http://centerforgamescience.org/portfolio/refraction/>5 <http://cpntools.org/>

http://www.gatesfoundation.org/

http://centerforgamescience.org/portfolio/refraction/

http://cpntools.org/

17

2 Fundamentação Teórica e Trabalhos Rela-cionados

Rede de Petri (RP) constitui a principal fundamentação teórica deste trabalho.Desta forma, elas são descritas neste capítulo, destacando-se os seus aspectos relevantespara o desenvolvimento de jogos eletrônicos.

2.1 Redes de PetriAs Redes de Petri (RPs) foram originalmente descritas por Carl Adam Petri em

sua tese de doutorado intitulada Kommunikation mit Automaten (Comunicação entreAutômatos), defendida em 1962 (PETRI, 1962). A partir de então, consideráveis trabalhosteóricos e aplicações práticas com RP têm sido realizados, principalmente nas áreasde modelagem de software e hardware, redes de computadores, comunicações, sistemasdistribuídos, protocolos de comunicação, sistemas operacionais, sistemas de controle deprodução, automação industrial, modelagem de controladores lógicos, análise de fluxo detarefas, chips VLSI, modelagem de sistemas a eventos discretos (JENSEN; KRISTENSEN,2009).

As RP são uma ferramenta matemática e gráfica, para modelagem, análise, con-trole, validação e implementação de muitos sistemas, especialmente os que possam serinterpretados como sistemas a eventos discretos (MURATA, 1989), (PETERSON, 1981).Uma RP é um tipo de grafo bipartido e direcionado, em que os arcos nunca ligam doisnós do mesmo tipo. A Figura 1 apresenta os elementos gráficos que compõem uma RP.

Figura 1 – Ilustração de uma RP.

Na Figura 1, p1 e p2 são os lugares, t1 é a transição. Neste caso, p1 é um lugar deentrada de t1 e p2 é um lugar de saída de t1. O arco que liga p1 a t1 possui peso 1, quepode ser representado pelo número “‘1” ou por um arco vazio (como visto na Figura 1). Oarco que liga t1 a p2 possui peso 2. Próximo ao lugar p1, o valor “1” indica a presença deuma ficha neste lugar.

Nas RP, a ocorrência de um evento está associada ao disparo de uma transição eos lugares de entrada e saída da transição representam, respectivamente, as pré-condiçõese pós-condições associadas à ocorrência do evento. Os arcos de entrada de uma transição

Capítulo 2. Fundamentação Teórica e Trabalhos Relacionados 18

tj têm origem em um ou mais lugares de entrada pi de tj e terminam na transição tj; osarcos de saída têm origem na transição tj e terminam em um ou mais lugares de saída pi

de tj. Conforme a Figura 1, o lugar p1 é entrada de t1, visto que um arco se origina emp1 e termina em t1. O lugar p2 é saída de t1, visto que um arco de peso 2 se origina emt1 e termina em p2.

As fichas são usadas nas RPs para simular a dinâmica e as atividades concorrentesdo sistema. O estado de uma RP é representado por um número ki de fichas contidas emcada lugar pi, chamada marcação, conforme apresentado na Figura 1. O estado do sistemaé dado pela distribuição de fichas nos lugares da RP e cada lugar representa um estadoparcial do sistema. A mudança de estado é representada pelo movimento de fichas na RP,que acontece quando ocorre o disparo de transições. Cada evento que ocorre no sistema éassociado ao disparo de uma transição no modelo RP. O disparo de uma transição significaque o seu evento correspondente ocorreu.

Uma transição é considerada habilitada se cada lugar de entrada da transiçãocontém um número de fichas maior ou igual ao peso do arco que o conecta à transição.Uma transição habilitada pode ou não disparar. Quando ocorre o disparo de uma transição,fichas são removidas dos lugares de entrada da transição e fichas são adicionadas aoslugares de saída. A quantidade de fichas removidas e acrescentadas depende do peso doarco. A nova marcação resultante do disparo da transição representa o novo estado dosistema. A marcação inicial M0 representa o estado inicial da RP.

2.1.1 Definição formal de uma RP

A definição formal de uma RP é apresentada a seguir (MURATA, 1989).

Uma RP é uma 5-upla, PN = (P, T, F, W, M0) em que:

• P = p1, p2, .., pm é um conjunto finito de lugares;

• T = t1, t2, ..., tn é um conjunto finito de transições;

• F ⊆ (P × T ) ∪ (T × P ) é um conjunto de arcos (fluxo de relações);

• W : F → 1, 2, 3... é uma função peso;

– w(p, t) peso do arco que liga o lugar à transição;

– w(t, p) peso do arco que liga a transição ao lugar;

• M0 : P → N∗ é a marcação inicial, em que N denota os números naturais e M0 amarcação inicial;

– P ∩ T = ∅ e P ∪ T 6= ∅


2.1.2 Comportamento dinâmico das RPs

O comportamento dinâmico das RPs obedece à regra de disparo de transições, asaber:

• uma transição é dita habilitada se cada lugar de entrada p de t é marcado com pelomenos w(p, t) fichas, em que w(p, t) é o peso do arco de p para t;

• uma transição habilitada pode ou não disparar;

• o disparo de uma transição t remove w(p, t) fichas de cada lugar de entrada p de t, eadiciona w(t, p) fichas a cada lugar de saída p de t, em que w(t, p) é o peso do arcodirecionado de t para p.

A RP apresentada na Figura 2 ilustra a regra de disparo através da modelagemdo comportamento dinâmico de um sistema e sua evolução. A Figura 2(a) apresentao estado inicial do sistema. A mudança de estado, que acontece através do disparo datransição t1, é apresentada na Figura 2(b). Na Figura 2(a), existem duas fichas no lugarde entrada p1 e nenhuma ficha no lugar de saída p2. A marcação da rede é M0 = (2, 0).Nesta marcação a transição t1 está habilitada e pode disparar. Conforme apresentadona Figura 2(b), no disparo da transição t1, fichas são removidas do lugar de entrada p1e fichas são adicionadas ao lugar de saída p2, originando uma nova marcação ou estadodo sistema M1 = (1, 2). Como pode ser observado neste exemplo, a quantidade de fichasremovidas do lugar de entrada e adicionada ao lugar de saída depende do peso dos arcos.

Figura 2 – Representação do disparo da transição t1.

2.1.3 Propriedades e Métodos de Análise de RPs

A aplicação de RP na modelagem de sistemas tem a vantagem de permitir verificaras propriedades dos modelos construídos através dos métodos de análise formais, a saber:Árvore (Grafo) de Alcançabilidade ou Cobertura, Matriz de Incidência e Equação de Estadoe Técnicas de Redução e Decomposição (MURATA, 1989), (JENSEN; KRISTENSEN,2009). A análise das propriedades das RP com estes métodos pode revelar informaçõesimportantes sobre a estrutura e comportamento do sistema modelado, permitindo aoprojetista realizar modificações e as correções antes da implementação. Algumas destaspropriedades são:


• (Liveness – vivacidade) permite saber se um sistema não possui bloqueio (deadlock)e se todos os elementos do sistema estão ativos;

• (Reversibility – reversibilidade ou reinicialização) permite saber se o sistema é capazde sempre retornar ao estado inicial após uma tarefa realizada;

• (Boundedness – limitação) permite verificar a consistência de um sistema quantoaos limites de sua capacidade de armazenamento e de realização de tarefas.

Em geral, os sistemas do mundo real são complexos e possuem vários processos comcaracterísticas similares, mas não idênticos. As RP possuem apenas um tipo de ficha, quepode ser inteiro ou booleano. O fato das RP não manipularem tipos de dados diferentes,dificulta a modelagem de sistemas reais e complexos (JENSEN; KRISTENSEN, 2009).

Para modelar sistemas reais, muitas vezes é necessário construir várias sub-redesindependentes com estruturas basicamente idênticas para processos similares. Isto podetornar o modelo RP extremamente grande, dificultando o desenvolvimento do projetoe a visualização dos modelos na sua totalidade. Além disso, pode ser difícil observarsimilaridades e diferenças entre as redes individuais que representam as partes similares.Outro fato é que as RPs não tratam de restrições de tempo, características inerentes aossistemas reais.

Para contornar estes problemas foram desenvolvidas extensões de RP. Tais extensõessão capazes de descrever sistemas mais complexos de forma mais compacta. Dentre eles,pode-se citar a Rede de Petri Coloridas (RPC), que são RP de alto nível, e as RP comrestrições de tempo (JENSEN; KRISTENSEN, 2009).

Nesta dissertação são utilizadas as RPC. Uma introdução desta extensão das RP éapresentada em seguida.

2.2 Redes de Petri ColoridasA Rede de Petri Colorida (RPC) é uma linguagem gráfica para a construção de

modelos de sistemas a eventos discretos e análise de suas propriedades. RPCs são umalinguagem de modelagem que combina as capacidades das Redes de Petri (RPs) com osrecursos de uma linguagem de programação de alto nível (JENSEN; KRISTENSEN, 2009).

A linguagem de programação das RPC é a CPN ML, que se baseia na linguagem deprogramação funcional Standard ML (ULLMAN, 1998). RPC são destinadas ao uso prático,em especial, porque elas permitem a construção de modelos compactos e paramétricos. Avantagem das RPCs sobre as outras RPs é a capacidade de modelar sistemas complexos efornecer modelos com um alto nível de abstração e da representação gráfica (JENSEN;KRISTENSEN, 2009).


O tempo desempenha um papel significativo numa vasta gama de sistemas concor-rentes. O funcionamento correto de alguns sistemas depende crucialmente do tempo tomadopor certas atividades. Diferentes decisões de projeto podem ter um impacto significativosobre o desempenho de um sistema. RPC incluem um conceito de tempo que faz com queseja possível capturar o tempo tomado por eventos no sistema. Isto significa que as RPCspodem ser aplicadas para a análise de desempenho baseada em simulação para investigarmétricas, tais como atrasos, taxa de transferência e tamanho de fila, e para a modelageme validação de sistemas de tempo real.

Modelos RPCs podem conter diferentes níveis de abstração. Podem ser construídosem um conjunto de módulos, que são importantes quando lidamos com modelos de sistemasde grande porte. Os módulos interagem uns com os outros através de um conjunto deinterfaces bem definidas, de uma forma semelhante às linguagens de programação. Oconceito de módulos em RPC baseia-se num mecanismo de estruturação hierárquica, oque permite que um módulo tenha sub-módulos que podem ser reutilizados em diferentespartes do modelo. Esses módulos são representados na rede por meio de transições, quesão chamadas de transições de substituição. Tais elementos formam as características dasRedes de Petri Coloridas Hierárquicas (RPC Hierárquica).

Demonstraremos ao longo deste trabalho que as RPCs são ferramentas adequadaspara a modelagem de jogos, pois fornecem recursos importantes, como a modularidade,facilidade de manutenção e capacidade de expansão. Estas características permitem aadição de novos processos ao modelo original, tornando possível adicionar novas funçõesou novos processos ao sistema.

O CPN Tools1 é uma ferramenta para edição, simulação, análise de espaço deestado, e análise de desempenho de modelos RPCs. O usuário do CPN Tools trabalhadiretamente com a representação gráfica do modelo RPC (JENSEN; KRISTENSEN, 2009).

2.2.1 Estrutura principal de uma Rede de Petri Colorida

A Figura 3 mostra a estrutura principal de um modelo RPC, constituído porlugares, transições e arcos. Com RPC, é possível usar os tipos de dados e manipulação dedados complexos.

Os lugares armazenam os dados (fichas) que representam o estado do sistemamodelado. Os nomes dos lugares são escritos dentro das elipses e não têm nenhumsignificado oficial, mas eles têm enorme importância prática para a legibilidade de ummodelo RPC. Cada lugar pode ser marcado com uma ou mais fichas, e cada ficha temum valor de dados ligado a ele. Este valor de dados é chamado cor da ficha. É o númerode fichas e as cores das fichas nos lugares individuais que, em conjunto, representam o1 <www.cpntools.org>

www.cpntools.org


Figura 3 – Representação de uma RPC.

estado do sistema. Isto é chamado uma marcação do modelo RPC. As fichas em um lugarespecífico constituem a marcação daquele lugar. Por exemplo, na Figura 4 o lugar1 possuiduas fichas do tipo STRING com o valor cor1 e cinco fichas do tipo STRING com o valorcor2, e o símbolo “++” significa que ainda existe uma ficha após a ficha anterior a estesímbolo.

Figura 4 – Marcação de um lugar com duas fichas do tipo STRING.

O tipo de ficha pode ser dos tipos básicos (int, string, boolean, real, unit), alémdos tipos with, product, record e list; ou de qualquer tipo de uma constante definidapelo projetista da rede (AALST; STAHL, 2011). Isso permite a representação de estadoscomplexos para o sistema.

2.2.2 Comportamento dinâmico das RPCs

As transições representam os eventos que podem ocorrer no sistema. Tal comoacontece com os lugares, os nomes das transições são escritos dentro dos retângulos.Quando a transição ocorre, ele remove fichas de seus lugares de entrada (lugares que têmum arco que conduz à transição) e adiciona fichas aos seus lugares de saída (lugares que


têm um arco proveniente da transição). As fichas que são removidas dos lugares de entradae adicionadas aos lugares de saída, quando ocorre uma transição, são determinadas pormeio das expressões de arco, que são as inscrições textuais posicionadas ao lado dos arcosindividuais. As expressões de arco são escritas na linguagem de programação CPN ML esão construídas a partir de variáveis, constantes, operadores e funções. Quando todas asvariáveis em uma expressão são ligadas a valores do tipo correto, a expressão pode seravaliada.

No exemplo da Figura 4, utiliza-se uma variável a do tipo STRING na inscriçãodo arco de saída de lugar1, o que indica que qualquer ficha do tipo STRING pode sereliminada de lugar1, independentemente do seu valor. Além disso, o arco de entrada emlugar2 utiliza a mesma variável, o que significa que a ficha que será depositada nestelugar após o disparo da transição tr1 possuirá o mesmo valor daquela que foi eliminadade lugar1. É possível que o número de fichas que são removidas de um lugar de entradaseja diferente do número de fichas depositadas no lugar de saída, o que se pode fazeratribuindo-se pesos diferentes aos arcos de entrada e de saída.

Além disso, nas RPCs, diferente das RPs originalmente idealizadas por Carl AdamPetri, os próprios valores das fichas que são removidas de lugares de entrada e depositadasem lugares de saída, a partir de disparos de transições, podem ser distintos, como se podeobservar no exemplo da Figura 2. Isto permite representar a transformação dos dados apartir da ocorrência de eventos. Por outro lado, com modelagens semelhantes a que foiapresentada na Figura 4 é possível simular o “movimento de fichas” entre dois lugares apartir do disparo de uma transição. Todas as características explicadas são úteis para amodelagem de jogos, como será abordado nos capítulos 3 e 4.

As transições podem possuir uma guarda, que é uma expressão booleana. Quandouma guarda está presente, ela deve ser avaliada como verdadeira para que a transiçãopossa ser habilitada, caso contrário, a transição estará desabilitada e não pode ocorrer.Assim, uma guarda coloca uma restrição adicional sobre a habilitação da transição.

2.2.3 Geração do Espaço de Estados com o CPN Tools

Dentre as ferramentas disponíveis para análise oferecidas pelo CPN Tools, é permi-tido gerar o Espaço de Estados (EE), que é um grafo direcionado ligando o conjunto detodos os estados possíveis da RPC. O EE da RPC mostrada na Figura 4 é apresentado naFigura 5, em que cada nó representa um estado da rede. Cada nó do EE é identificadopor três números distintos. O primeiro número, que fica posicionado acima dos outros,representa o identificador do nó (ou de um estado da RPC). Abaixo do identificador, osegundo e o terceiro números, da esquerda para a direita e separados por “:”, representamquantos nós (estados) anteriores e quantos nós (estados) sucessores o nó identificado possui,o que mostra a relação de sucessão entre os diferentes estados da rede.


Por exemplo, a partir da verificação do EE da Figura 4, percebe-se que o estadoidentificado por 1 não possui estado anterior, correspondendo, portanto, ao nó que detéma marcação inicial do sistema. Por outro lado, o nó 18 mostra a ausência de estadossucessores, o que indica um estado de bloqueio no sistema.

Figura 5 – Exemplo do grafo do espaço de estados da RPC da Figura 4 gerado na ferra-menta CPN Tools.

Outros instrumentos de análise são oferecidos pelo CPN Tools. Aqueles dentre osquais foram utilizados neste trabalho são discutidos mais detalhadamente no Capítulo 3.

2.2.4 Temporização em RPCs

Com um modelo RPC temporizado, medidas de desempenho, tais como compri-mento máximo da fila e média de tempo de espera, podem ser calculadas. Pode-se verificar,também, se a operação de um sistema em tempo real obedece os prazos exigidos.

Em um modelo de RPC temporizado, as fichas podem transportar um selo detempo, além de sua cor. Isto significa que a marcação de um lugar em que as fichaspossuem selo de tempo é agora um multiconjunto temporizado. Além disso, o modelo RPCpossui um relógio global que representa o tempo de modelo. A distribuição das fichas noslugares, em conjunto com as suas temporizações e o valor do relógio global, é chamada demarcação temporizada. Mesmo num modelo RPC hierárquico temporizado há um únicorelógio global. O selo de tempo especifica o tempo em que a ficha está pronta para serutilizada, ou removida por uma transição que ocorre.

Retardos de tempo podem ser implementados nos arcos e nas transições. Se houverum tempo de retardo em uma transição, a sua ocorrência adiciona o valor do retardo atodas as fichas de saída que carregam um selo de tempo. Se há um tempo de retardoassociado a um arco de saída de uma transição, o retardo é adicionado apenas para asfichas temporizadas que são colocadas no lugar de saída associado a esse arco.

2.3 Trabalhos relacionados a jogos usando Redes de PetriExistem vários trabalhos na literatura que apresentam ferramentas de criação de

jogos com pouco esforço de programação por parte do projetista do jogo. Dentre esses


trabalhos, pode-se citar o trabalho de (ORWANT, 2000). O autor apresenta a ferramentaEGGG (Extensible Graphical Game Generator), que possibilita ao projetista criar jogoscom o mínimo de programação possível. Essa ferramenta permite a descrição, por partedo projetista, da estrutura do jogo e de seu enredo, mas o foco principal é no processo dojogo. A descrição do jogo é realizada por meio de um conjunto de regras que o projetistadeve definir em um arquivo EGGG (com a extensão .egg). Apesar dessas regras poderemaparecer em qualquer ordem, o projetista deve ter conhecimento prévio de todas as regrasantes de escrevê-las no arquivo de configuração. Por ser um arquivo de configuração, aquantidade de linhas escritas é visivelmente menor do que comparado à quantidade delinhas de código de um jogo similar. Projetada na linguagem Perl, essa ferramenta aindaprecisa que o projetista programe algumas regras nessa linguagem de programação. Outralimitação da ferramenta EGGG é que ela não fornece instrumentos para a análise ouverificação prévia da corretude das regras, apenas gerando o jogo.

As RPs vêm sendo empregadas para dar suporte ao desenvolvimento de jogos emalguns trabalhos. Os trabalhos de (LEE; CHO, 2011), (LEE; CHO, 2012), (ARAÚJO;ROQUE, 2009), (SANTOS; ROQUE, 2010) são alguns exemplos de geradores de trama dejogos utilizando a teoria de RP.

(LEE; CHO, 2011) propõem um método baseado em RP para gerar pequenasmissões ou tarefas para personagens principais que representam o jogador em um jogo. Osmesmos autores apresentam em (LEE; CHO, 2012) uma ferramenta chamada PlotWizardpara dar suporte ao desenvolvimento, pelo próprio jogador, da história do jogo. Entretanto,o formalismo baseado em RP no referido trabalho suporta apenas a especificação de comoos personagens interagem, não interferindo nas propriedades gráficas e de controle do jogo.Os estados do jogo que são mapeados para RP são estáticos e limitados em quantidade,diminuindo o poder de abstração proporcionado pelas RP.

(ARAÚJO; ROQUE, 2009) apresentam a modelagem do fluxo de um jogo emRP como uma alternativa mais robusta às modelagens em UML e Fluxogramas. Osautores usam a navegação e mapeamento de costas e rotas marítimas como estudo de caso.Entretanto, nessa abordagem não há a geração automática do jogo nem das redes que orepresentam.

(SANTOS; ROQUE, 2010) apresentam uma implementação automática de modelosem RP com o intuito de realizar alterações dinâmicas no jogo de modo a estimular ojogador. Para controlar o comportamento de cada agente, é modelada uma RP, em quenela os agentes são controlados por inteligência artificial. A RP é ajustada de acordo como comportamento do agente em cada sessão. Para os agentes que não são controlados pelojogador, o sistema verifica quais foram os arcos que tiveram mais passagens de tokens.Se o agente tiver sucesso, os arcos com mais passagens são mantidos e os outros arcossão substituídos por arcos escolhidos em forma de sorteio. Caso contrário, os arcos são


retirados. Esse estudo apresenta a modelagem do comportamento dos elementos do jogopor meio de RP, mas não possibilita a criação nem a geração automática da estrutura dojogo.

Os trabalhos citados não permitem representações hierarquizadas ou o uso de fichasestruturadas, entre outras características das RPs de Alto Nível. Além disso, não foramencontrados trabalhos que permitam a geração direta de jogos eletrônicos (ou games) apartir de modelos em RP.

Neste trabalho busca-se, por meio das RPCs, a construção e a geração automáticade jogos, a concepção de jogos com múltiplos níveis e multiusuário e, por fim, a criação deNon-Player Character (NPC).

A abordagem adotada neste trabalho para se alcançar os objetivos elencados é ainstanciação de jogos a partir da interpretação direta de modelos construídos em RPCs.Para isso, um conjunto de regras e convenções de modelagem foi estabelecido.

No próximo capítulo, são apresentadas regras de modelagem e os mecanismosadotados para a geração de jogos a partir de modelos em RPC.

27

3 Modelagem de Jogos de Concepção Sim-ples com Redes de Petri Coloridas

Os jogos tratados neste trabalho são limitados aos jogos de concepção simples,com interfaces bidimensionais, mas permitindo a existência de múltiplos níveis e o acessopor múltiplos usuários de maneira simultânea. Para que se possa criar jogos com essascaracterísticas a partir de Rede de Petri Colorida (RPC), foi preciso definir um conjuntode regras e convenções de modelagem, que são apresentadas e discutidas nas próximasseções.

3.1 Os elementos do jogo e a movimentação de personagensConforme apresentado no Capítulo 2, a estrutura básica das RPs são os lugares,

arcos e transições, que são representados por elipses, arcos direcionais e retângulos, respec-tivamente. Adotou-se neste trabalho a convenção de que os lugares da RPC representamregiões do jogo e devem ser formatados como figuras na interface bidimensional do jogo.Eles compreendem, portanto, as regiões para as quais os personagens podem se deslocar.As imagens dos lugares são posicionadas na interface do jogo de acordo com a posiçãomodelada na ferramenta CPN Tools.

As transições, por sua vez, configuram os caminhos pelos quais um personagempode se mover, desde que obedeçam às regras de deslocamento que são impostas namodelagem.

Os personagens são representados no modelo em RPC por fichas. Portanto, umaficha em um lugar da RPC representa um personagem na região correspondente a estelugar na interface do jogo.

Os personagens (correspondentes às fichas) são representados no jogo por elementosgráficos definidos como sprites. Logo, uma ficha em um lugar na RPC identifica um spritena região correspondente a este lugar na interface do jogo. As propriedades das fichascaracterizam os personagens, diferenciando-os uns dos outros. As fichas podem contertipos elementares ou tipos estruturados.

Adotou-se a convenção de que, ao disparo de uma transição, a remoção de umaficha de um lugar de entrada e a inclusão de uma ficha com as mesmas característicasem um lugar de saída representam o deslocamento de um personagem entre as regiõescorrespondentes.

Para ilustrar as regras e convenções apresentadas até aqui, é apresentado o jogo

Capítulo 3. Modelagem de Jogos de Concepção Simples com Redes de Petri Coloridas 28

Figura 6 – Modelagem didática de uma RPC.

didático Planet Tour. Na Figura 7 é ilustrada a relação entre a interface do jogo (quepossui um mapeamento contínuo) e os elementos de um modelo em RPC (que possui ummapeamento discreto) apresentado na Figura 6. Estão sendo omitidos, presentemente, omecanismo como o usuário interage com o jogo e a forma de associação entre as imagensda interface gráfica e os elementos da RPC. Estes serão detalhados no próximo capítulo.

Figura 7 – Planet Tour gerado a partir da rede apresentada na Figura 6.

De acordo com o modelo em RPC da Figura 7, estabeleceu-se que um personagempode navegar do planeta da esquerda para o planeta da direita. Caso as regras do jogofossem estabelecidas de maneira que os personagem pudessem apenas realizar o movimentoda direita para a esquerda e vice-versa, o modelo deveria ser modificado conforme ilustrado


na Figura 8.

Figura 8 – Modificação da rede da Figura 6 para permitir o movimento de personagens dadireita para a esquerda no jogo Planet Tour.

Após a modificação do modelo, o personagem pode voltar ao estado inicial da rede,como pode ser visto na Figura 9.

Figura 9 – Personagem voltando ao estado inicial do jogo.

Redes mais complexas, envolvendo um número maior de lugares e transições podemser elaboradas com as convenções de modelagem discutidas. Na Figura 10 é apresentadoum novo modelo para o jogo Planet Tour. Essa nova modelagem contém dois personagens,que são representados pelos valores inteiros 1 e 2. A marcação 1‘1 + +1‘2 significa apresença de uma ficha com o valor 1 e uma ficha com o valor 2 no lugar planet4.

Segundo as regras estabelecidas nesse modelo, os personagens podem se deslocarentre os planetas (abstração feita para os lugares neste exemplo de jogo) de acordo com asregras modeladas na RPC. Portanto, personagens do jogo modelado conforme a Figura 10podem percorrer os planetas nos seguintes sentidos: planet1 para planet2, planet2 paraplanet3, planet3 para planet4, planet4 para planet1, planet2 para planet4 e planet4 paraplanet3.


Figura 10 – Modelagem do jogo Planet Tour em uma Rede de Petri Colorida Hierárquica.

3.2 Representação de múltiplos níveisFoi convencionado, neste trabalho, o uso das sub-redes de um modelo em RPC

hierárquica para a representação de diferentes níveis ou espaços de um jogo. Dessamaneira, disparar uma transição de substituição significa entrar em um novo ambiente.O ambiente relativo à sub-rede contém, portanto, os seus próprios lugares, transições eregras particulares de movimentação, incluindo possíveis mecanismos de retorno ao nívelanterior.

Como apresentado na fundamentação teórica, as hierarquias em uma RPC sãoespecificadas por meio de transições de substituição. Estas são representadas por retângulosde borda dupla, como a transição identificada por t5 da Figura 10. Neste exemplo, atransição t5 da Figura 10 é a abstração da sub-rede apresentada na Figura 11 que, porsua vez, possui uma transição de substituição t9, cuja sub-rede é apresentada na Figura12. Essas representações podem ser interpretadas como novas fases ou fase bônus do jogo.

Dessa maneira, na interface do jogo, ao deslocar um sprite para uma transiçãode substituição, a personagem é transferida para outro domínio, em que a estrutura dedeslocamento é constituída por novos lugares e transições que são associados por regrasdistintas em relação àquelas do nível anterior. Do ponto de vista da interface gráfica, odeslocamento para uma transição de substituição implica na mudança da fase do jogo,com consequente modificação da imagem de fundo e dos demais elementos que constituemessa nova fase.


Figura 11 – Sub-rede t5 da transição t5 da rede da Figura 10.

Figura 12 – Sub-rede t9 da transição t9 da rede da Figura 11.

3.3 Simulação e análise através do modelo RPCA análise formal do modelo RPC permite validá-lo em relação a algumas de suas

propriedades estruturais e comportamentais. O CPN Tools oferece recursos para realizaçãode análises em redes complexas e pode ser feita, como discutido por (AALST; STAHL,2011), de diferentes maneiras:

• por validação, utilizando os recursos de simulação do CPN Tools, em que se podeverificar a sua dinâmica de maneira interativa. A imagem à esquerda da Figura 7mostra um exemplo em que se pode simular e observar a modificação do estado domodelo de um jogo para validar a regra de movimentação do personagem (1‘1) dolugar1 para lugar2, o que pode ser feito antes da concepção definitiva da interfacedo jogo.

• por verificação de propriedades, utilizando mecanismos como a geração de grafos


com o espaço de estados ou a geração de relatórios, que podem indicar, por exemplo,a presença de transições mortas.

• por análise de desempenho, utilizando monitores do CPN Tools, que são capazesde rastrear e registrar informações coletadas ao longo da execução de uma simulação.

Para realizar a análise, o projetista deve seguir os passos apresentados nos próximosparágrafos.

Figura 13 – Palheta para o cálculo do Espaço de Estados na ferramenta CPN Tools.

A Figura 13 apresenta a palheta que disponibiliza as funcionalidades referentesao cálculo do espaço de estados. Para que seja iniciado o cálculo do espaço de estados,o projetista deverá clicar no botão indicado pelo número 1, clicar em cima da rede e aferramenta irá mostrar a mensagem de que o cálculo foi realizado com sucesso (bolha demensagens verde), como pode ser visto na Figura 14a. Em seguida, o projetista deveráclicar no botão indicado pelo número 2 da Figura 13 e depois sobre a rede, para podercalcular o grafo componentes fortemente conectados (strongly connected componente –SCC ) (mensagem da ferramenta apresentada na Figura 14b). Ao clicar no botão donúmero 3 da Figura 13, o usuário irá escolher em qual diretório ele deseja salvar o relatórioresultante da análise. O relatório gerado tem o formato de texto e pode ser salvo tanto em.txt, .rtf, ou outra extensão de preferência do usuário. No final, a ferramenta irá mostrar amensagem de confirmação, como visto na Figura 14c.

Caso seja de interesse do projetista, também é possível realizar a análise de formagráfica. Para tal, é necessário ter concluído os passos descritos no parágrafo anterior. Parauma melhor visualização do grafo, o projetista deve criar uma nova página no CPN Tools,como apresentado na Figura 15a. Nessa nova página, o projetista deve iniciar o grafo doespaço de estados clicando no botão de número 4 da Figura 13 e clicando dentro da novapágina (Figura 15b). O passo apresentado na Figura 16a é a criação dos outros nós apartir da funcionalidade do item 5 da da Figura 13. A imagem resultante da geração dografo é apresentado na Figura 16b.

Para qualquer alteração na rede, deve ser realizada uma nova análise do espaço deestados.


(a) Espaço de estados. (b) Grafo SCC.

(c) Relatório.

Figura 14 – Mensagens do resultado dos cálculos realizados pela ferramenta CPN Tools.

(a) Criação de uma nova página noCPN Tools

(b) Início da geração do grafo do espaçode estados.

Figura 15 – Passos para a geração do grafo do espaço de estados

(a) Geração do grafo do EE. (b) Grafo do EE gerado.

Figura 16 – Passos para a geração do grafo do espaço de estados


A partir do relatório de análise gerado pelo CPN Tools, o projetista pode verificaras propriedades padrões da RPC, tais como se a rede é limitada (bounded), se ela possuimarcações mortas (deadlock), se todas as transições são habilitadas a partir de umamarcação qualquer (liveness, deadlock free), se toda marcação é alcançável a partir dequalquer outra marcação (home-marking), e se a partir de qualquer marcação é possívelvoltar à marcação inicial (rede reversível). Essas propriedades podem ser verificadas apriori em modelos construídos em RPC que foram concebidos para a geração de jogos,de maneira a validar regras para eles estabelecidas antes mesmo da fase de acabamentoe execução do jogo. Por exemplo, em um determinado jogo, pode-se querer verificar ainexistência de regiões cujo trânsito seja impedido. Em outro, pode-se querer verificar se épossível haver mais de uma ficha (personagem) em um determinado lugar. Tais verificaçõespodem ser realizadas pela emissão de relatório de análise do CPN Tools.

Para exemplificar, será analisada a existência de um bloqueio (deadlock) usandouma modificação do modelo da Figura 10. Se a transição t1 for removida, os sprites quechegarem no lugar planet1 não podem mais sair de lá, o que caracteriza uma situação dedeadlock (essa modificação está ilustrada na Figura 17). Além da exclusão da transição t1,os arcos da transição t10 tiveram as respectivas direções modificadas.

Figura 17 – Rede da Figura 10 sem a transição t1.

O deadlock, bem como outras propriedades, pode ser constatado durante umasimulação, pode ser verificado também por análise do espaço de estados da RPC ou, ainda,através do relatório de análise gerado pelo CPN Tools. Para o exemplo apresentado naFigura 17, gerou-se o relatório de análise (apresentado na Figura 18) a partir da marcaçãoinicial estabelecida no modelo (1‘2 + +1‘1 no lugar planet4 da Figura 10).


O relatório pode conter dados de acordo com a necessidade de análise do projetista.Neste trabalho são utilizadas as opções padrão da ferramenta, porém o projetista podeeliminar qualquer uma delas no momento da geração do relatório. Utilizando a Figura18 como suporte, pode-se verificar que essas opções fornecem: (1) os dados estatísticos(dados do espaço de estados); (2) as propriedades de limitação; (3) as propriedades damarcação; (4) propriedades de vivacidade (marcação morta e instancias de transições vivasou mortas); (5) propriedades de justiça de transições (fairness) (KRISTENSEN, 2010). Ositens 4 e 5 só podem ser calculados se o projetista tiver realizado o passo da Figura 14b.

A parte 1 do relatório da Figura 18 mostra que as marcações alcançáveis do grafodo espaço de estados foi gerado completamente (Status: Full). Também é apresentada aquantidade de nós (Nodes: 48 ), arcos (Arcs: 116 ) e o tempo que foi gasto na construçãodo grafo do espaço de estados (Secs: 0 ).

A parte 2 apresenta a quantidade máxima e mínima de fichas em um lugar (BestIntegers Bounds) para qualquer marcação alcançável, bem como a especificação das corespossíveis (Best Upper Multi-set Bounds e Best Lower Multi-set Bounds).

A parte 3 mostra a marcação que é alcançada a partir de todas as outras marcaçõesda rede.

A parte 4 apresenta três características da rede: (i) se há alguma marcação quenão possui transições habilitadas (marcação morta); (ii) se há alguma transição que não éhabilitada em nenhuma marcação alcançável; (iii) se há alguma transição que pode serhabilitada a partir de qualquer marcação alcançável. Como a marcação 11 é uma marcaçãomorta, então, não existe nenhuma transição que seja habilitada para todas as marcações(live transition instances - none). Da mesma forma, não existe nenhuma transição que nãoseja habilitada pelo menos para uma marcação (dead transition instances - none).

A parte 5 trata da propriedades do grafo SCC (fairness). Esta propriedade dáinformação sobre a frequência de ocorrência de transições em uma sequência de disparoinfinita. Um transição é imparcial se ela pode ser disparada em todas as sequências dedisparo infinitas. Na figura, apenas a transição t43 pode disparar nas duas sequênciasexistentes (“t3 – planet4 – t43 – planet3 – t3” e “t5 – planet4 – t43 – planet3 – t10 –planet2 – t5”). Como existe um deadlock, então, não existem fair transition instances nemjust transition instances.

Para melhor visualização do relatório apresentado na Figura 18, consultar o Apên-dice A.

Todas estas propriedades que foram apresentadas no relatório da Figura 18 ajudamo projetista a realizar a análise do jogo modelado. Pode-se verificar que qualquer jogadorem qualquer estado da rede pode chegar ao estado 11 (Home markings); quando o jogochega ao estado equivalente ao estado 11, nenhum jogador poderá mais sair do planeta


Figura 18 – Relatório gerado pela ferramenta CPN Tools a partir da rede da Figura 17.

(Dead Markings) pois, neste estado não existe nenhuma transição habilitada. Note que oestado 11 é, ao mesmo tempo, home marking e dead marking.

É importante que o projetista tenha ciência do que será útil para a análise do jogo.Por exemplo, o jogo da rede da Figura 17 pode ter como objetivo chegar ao lugar planet1,independente de sua marcação. Se esse fosse o objetivo do jogo modelado, para o exemploespecífico, não importaria se o jogo possui algum tipo de bloqueio naquele determinado


lugar.

A Figura 19 mostra o espaço de estados para a rede da Figura 17, gerado pela fer-ramenta CPN Tools. No espaço de estados apresentado, pode-se verificar a impossibilidadede mudança de estado após o estado de número 11. Essa verificação é feita pela ausênciade nós de saída.

Figura 19 – Gráfico do State Space gerado pela ferramenta CPN Tools a partir da rede daFigura 17.

3.4 Interpretação da Codificação de um modelo em RPCUma aplicação, denominada CPN Games, foi desenvolvida em Java para interpretar

o arquivo gerado pelo CPN Tools com a codificação da modelagem do jogo. O código daRPC é escrito em XML e gravado com a extensão .cpn, podendo, portanto, ser submetidoa um analisador sintático (parser) desenvolvido para essa linguagem. Além de interpretara representação do jogo modelado por RPC, o CPN Games permite também a associaçãode imagens e de sons aos elementos do jogo que serão instanciados para fazer a interfacecom o usuário no momento de sua execução.

No código gerado pelo CPN Tools, as estruturas fundamentais são representadaspor elementos XML (tags) denominados place, trans e arc, que são correspondentes,respectivamente, aos lugares, transições e arcos modelados na RPC. A Figura 20 apresentaum trecho de código de um arquivo com a extensão .cpn em que se pode observar lugares,transições e arcos codificados por suas tags correspondentes1.1 Para a visualização completa do código, visite: <https://sites.google.com/site/vanessaviana/

congressos/sbgames-2014/rede5.cpn?attredirects=0&d=1>

https://sites.google.com/site/vanessaviana/congressos/sbgames-2014/rede5.cpn?attredirects=0&d=1

https://sites.google.com/site/vanessaviana/congressos/sbgames-2014/rede5.cpn?attredirects=0&d=1


Figura 20 – Identificação de lugares, transições e arcos em um arquivo .cpn.

No CPN Games, são implementadas classes correspondentes a essas estruturas(respectivamente, às classes Place, Transition e Arc). Assim, no processo de análise sintática,todas as instâncias desses elementos são criadas e suas propriedades iniciadas conforme osatributos extraídos do modelo.

Devido à possibilidade de um modelo possuir transições comuns e transições desubstituição, sendo estas últimas as que são responsáveis pela mudança de fase ou nível dojogo, é necessário diferenciá-las entre si. Portanto, para identificar a existência de umasub-rede e compor os diferentes sub-níveis do jogo, é preciso identificar a ocorrência detransições de substituição. Essas transições de substituição ocorrem quando o elemento<trans>, que representa uma transição no arquivo .cpn, possui um elemento filho do tipo<subst>. Além disso, o atributo subpage do elemento <subst> contém o identificador dasub-rede que substitui a referida transição, o que permite carregá-la para apresentação dafase ou nível seguinte do jogo.

O trecho de código XML mostrado na Figura 21 contém a parte referente àmodelagem da rede da Figura 10. O código foi enumerado e reduzido para facilitar aexplicação. O código apresenta a especificação de um elemento.

Os itens apresentados na figura 21 são representados da seguinte forma: o elemento<trans> (item 1 da figura) apresenta o nó hierarquicamente mais alto na estrutura querepresenta uma transição. A tag <trans> possui dois parâmetros, sendo aproveitado paraeste trabalho apenas o primeiro deles, o parâmetro ID. O primeiro nó filho de <trans>é o <posattr> (item 2). Este identifica as coordenadas da transição na rede. Com basenessa posição, é calculada a posição relativa do elemento que representa o nó no jogo. Atag <text> (item 3), representa a identificação dada ao nó pelo projetista da rede. Nesseexemplo, o texto é “t5”. O nó <subst> (item 4) possui como atributos subpage e portsock,


Figura 21 – Início do XML de uma transição hierárquica.

caracterizando esse elemento como uma transição de substituição. O parâmetro subpage(item 5) contém o ID da sub-rede que a transição de substituição representa. Os valoresatribuídos ao parâmetro portsock (itens 6, 7, 8 e 9) representam a configuração das portas(ou sockets) de entrada e saída da rede e da sub-rede. O item 6 representa o lugar de saídada sub-rede, o item 7 representa o lugar de saída da rede, o item 8 representa o lugar deentrada da sub-rede, e o item 9 representa o lugar de entrada da rede.

O XML (.cpn) possui características necessárias para a interpretação da redemodelada e a apresentação do jogo ao usuário. Essa interpretação é composta pelomapeamento dos elementos e a relação entre eles, seguindo as propriedades das RPespecificadas no modelo. Ao interpretar os elementos descritos nessa sessão, a ferramentairá apresentar ao usuário a estrutura juntamente com as regras de execução modelada peloprojetista do jogo.

3.5 Representação gráfica dos elementos do modelo RPCAlém da interpretação do modelo com o CPN Tools, para que um jogo possa ser

efetivamente executado pelo CPN Games, é necessário associar cada elemento visível a umarquivo contendo a imagem que o representa. Um arquivo de configuração com o mesmo


nome daquele que contém o código da rede deve ser criado com a extensão .properties, comoo exemplo da Figura 22. Esse arquivo possui o caminho relativo de todas as imagens usadasno jogo. Nele também podem ser indicados os recursos de áudio que serão ativados a cadadisparo de uma transição e a representação de imagens para transições de substituição.

Figura 22 – Exemplo de um arquivo que define as propriedades gráficas e sonoras do jogo.

Após a construção do arquivo .properties pode-se carregar o game e jogar.

3.6 Exemplo do Jogo Gerado a partir do Modelo em RPCPara ilustrar o conjunto de regras e convenções apresentadas neste capítulo, é

apresentado um modelo em RPC completo contendo diferentes níveis. Com um conjuntode regras limitadas, definidas apenas para demonstrar o funcionamento da técnica desen-volvida, o objetivo deste exemplo é permitir que os jogadores naveguem entre diferentesgaláxias, sendo a passagem de uma galáxia a outra feita através de incursões em buracosnegros.

A imagem à direita da Figura 23 apresenta a interface do jogo gerado a partirda RPC da Figura 10. O jogo modelado define a estrutura do jogo e as regras parao deslocamento de personagens por vários planetas. Todas as imagens utilizadas parao desenvolvimento desse jogo foram retiradas do repositório livre OpenGameArt2. Omecanismo de associação de imagens e sons aos elementos da RPC, bem como a utilizaçãode recursos mais avançados, como os NPCs, serão detalhados no próximo capitulo.

A rede principal da aplicação, mostrada na Figura 10, representa a tela principalda aplicação, cuja renderização é mostrada na imagem à direita da Figura 23. Na redeprincipal, as sub-redes as transições de substituição representam os sub-níveis, por ondeos personagens podem se deslocar por meio de portais específicos. No exemplo de jogoapresentado na imagem à direita da Figura 23, esses portais são representados por umaimagem de um buraco negro. Assim, ao colidir com essa representação, o usuário migrapara um nível diferente. Apesar de não ser o caso do exemplo citado, regras mais complexaspodem ser estabelecidas via modelagem de maneira que apenas os sprites que tenhamalcançado determinadas propriedades possam mudar de nível (regras mais complexas sãodiscutidas no próximo capítulo).2 Imagens dos planetas obtidas em <http://opengameart.org/content/20-planet-sprites> e imagem do

sprite obtida em <http://opengameart.org/content/rocket>

http://opengameart.org/content/20-planet-sprites

http://opengameart.org/content/rocket


Figura 23 – À direita, o jogo gerado a partir da rede da Figura 10, apresentada à esquerda.

Na Figura 24 é apresentada a visão da interface que mostra dois jogadores queestão em níveis diferentes do jogo. Do lado esquerdo, tem-se um personagem que acabade migrar através do buraco negro apresentado na imagem à direita da Figura 23 para onível seguinte, que é estruturado de acordo com o modelo apresentado pela rede “t5” daFigura 11. No lado direito temos o personagem que atravessa o buraco negro da rede “t5”e chega à rede “t9”, cujo modelo é representado na Figura 12.

Figura 24 – Personagens em dois níveis diferentes do game, baseado nas sub-redes dasFiguras 11 e 12.


3.7 Efeitos de modificação no modelo em RPCO modelo em que foram definidas as regras e a estrutura do jogo pode ser modificado

exclusivamente a partir do CPN Tools. O novo modelo pode, então, ser carregado einterpretado pelo CPN Games. Para exemplificar esse procedimento, ao retirar-se o lugarcom o nome planet3 da rede da Figura 10, obtém-se a rede apresentada na Figura 25.

Figura 25 – Rede da Figura 10 sem o lugar planet3.

Em seguida, carregando-se o modelo modificado na ferramenta CPN Games, aimagem que representa o planet3 não será mais apresentada, como mostrado na Figura26. Para execução do jogo com essa modificação, não é necessária uma linha sequer deprogramação.

Modificações no jogo podem ser realizadas não só com a remoção, mas tambémcom a inserção de quaisquer outros elementos na rede. No exemplo da Figura 27, pode-sever que foi adicionado ao modelo um novo lugar com o nome planet9.

Após adicionar esse novo elemento na rede e realizar suas análises, a aplicação gerao jogo apresentado na Figura 28.

Ressalta-se que, após realizar qualquer alteração em modelos existentes, é impor-tante re-executar todos os procedimentos de análises e simulações por meio da ferramentaCPN Tools, como discutido na Seção 3.3.

3.8 Implementação da interação com o usuárioPara demonstrar o método de geração de jogos multiníveis e com múltiplos usuários

por meio de Modelagem em RPC proposto neste trabalho, o CPN Games implementa umainterface com o usuário para desktop, que contém os elementos necessários à representaçãodo jogo e à movimentação dos personagens a partir de interações do usuário via teclado.


Figura 26 – Geração do jogo Planet Tour relativo à rede da Figura 25.

Figura 27 – Rede da Figura 10 com o lugar planet9.

Além da implementação do jogo para desktop, foi desenvolvida uma interface paraa plataforma Android. Alguns aspectos característicos às plataformas móveis precisaramser levados em consideração e adaptados, tais como o tamanho da tela. Na implementaçãopara desktop, a câmera é fixa e o personagem se movimenta no cenário que está totalmenterenderizado na interface gráfica. Já na implementação para Android, apenas uma parte docenário é renderizada, e a câmera deve seguir o personagem durante o movimento.

Ao iniciar a aplicação CPN Games, uma tela de apresentação é renderizada junto auma pequena animação de fade in e fade out. Em seguida, o usuário escolhe em uma lista ojogo que deseja executar (o que corresponde a um modelo em RPC). Uma pré-visualizaçãodo jogo é apresentada ao lado de cada item da lista. Após a escolha do jogo, os recursos


Figura 28 – CPN Games apresentando a geração do game relativo à rede da Figura 27.

gráficos e sonoros são carregados para renderização da interface gráfica e a conexão com oservidor é estabelecida. Durante este processo, em que também é realizado o parsing daRPC, uma animação indica ao usuário que está sendo feito o carregamento do jogo. NaFigura 29 é mostrada a renderização resultante do processamento da RPC apresentada naFigura 10 mostrando os controles para movimentação.

Figura 29 – Jogo gerado a partir da RPC da Figura 10.

A conexão de um jogador e a sua dinâmica ao longo do jogo é percebida pelomovimento do seu sprite entre os lugares especificados na rede que são representados porimagens apropriadas na interface gráfica.


3.9 Execução em redeAlém das interfaces para o usuário em desktop e Android, a ferramenta permite que

jogadores participem do mesmo jogo em rede local, podendo ser expandido futuramentepara redes de longa distância. O modelo de distribuição usado no protótipo desenvolvido édo tipo Cliente-Servidor, em que um servidor centraliza o estado global do jogo. O servidorpode ser executado em um dispositivo móvel ou desktop. Um serviço de localização permiteidentificar servidores em uma rede local através de mensagens broadcast (ou multicast).

Com múltiplos jogadores, os sprites representantes dos diversos usuários são ren-derizados em cada interface cliente. A Figura 30 apresenta um jogo onde três jogadoresestão conectados na mesma fase.

Figura 30 – Jogo gerado a partir da rede da Figura 25.

Uma versão da análise da rede e a execução nas plataformas desktop e Androidpodem ser vistas no vídeo disponibilizado em: <http://goo.gl/kr2Acn>.

3.10 CPN Quiz : um Jogo Educativo de Perguntas e RespostasPara atribuir objetivos mais específicos ao Planet Tour, concebeu-se um estudo de

caso denominado CPN Quiz. O CPN Quiz é um jogo simples de perguntas e respostas,onde o jogador avança de nível quando acerta a resposta da pergunta do nível em que seencontra.

Com as perguntas e respostas já formuladas, o projetista do jogo deve criar asimagens que deverão representá-las. Essas imagens deverão possuir o mesmo nome doselementos modelados na RP. Usando o exemplo da Figura 31, o projetista do jogo deverá

http://goo.gl/kr2Acn


Figura 31 – Nível inicial da RPC Hierárquica modelada para o jogo.

criar uma imagem que representa o início do jogo (placeQuiz), um para cada caminhode volta (path1, path2, path3 ), as imagens que representam as transições de substituição(tema1, tema2, tema3 ), além das imagens dos outros níveis do jogo.

Figura 32 – Modelagem da transição de substituição trTema1 da rede apresentada naFigura 31.

Assim como a rede principal, as sub-redes foram modeladas de forma que o usuáriopossa avançar ao acertar a resposta, como pode ser visto nas Figuras 32 e 33. A tela inicialdo jogo pode ser vista na Figura 34 e a imagem do jogo relativa à rede da Figura 32 éapresentada na Figura 35.

3.11 Considerações FinaisNeste capítulo foram apresentadas as regras fundamentais de representação e os

mecanismos básicos para construção de jogos por meio de modelos. Entretanto, os exemplosque ilustram esse capítulo são limitados tanto na forma de representação dos elementosdo jogo em RPC como na definição de possibilidades de interação do usuário. As cores,que definem a estrutura das fichas para cada lugar da rede, foram associadas aos lugaressempre com o tipo INT (correspondendo a fichas de valor inteiro), limitando não só arepresentatividade proporcionada pelas RPCs, mas também as possibilidades de elaboração


Figura 33 – Modelagem da transição de substituição trTema2 da rede apresentada naFigura 31.

Figura 34 – Imagem do jogo resultante da modelagem da rede apresentada na Figura 31.

Figura 35 – Imagem do jogo relativo à rede da Figura 32.

de jogos mais ricos. No próximo capítulo são apresentados mecanismos mais elaborados derepresentação, com uso de cores de tipo estruturado e uma exploração mais aprofundadado trabalho com o arquivo de propriedades.

48

4 Configurações avançadas no CPN Games

Além das funcionalidades fundamentais apresentadas no capítulo anterior, nestecapítulo são apresentadas, de maneira detalhada, as regras e convenções para associarimagens aos elementos da rede e sons a eventos, oferecendo ao desenvolvedor recursos maisavançados para criação de jogos. Além disso, são apresentados os mecanismos pelos quais épossível criar personagens que não são controlados pelo usuário, os chamados NPC’s (NonPlayer Characteres). O usuário também pode receber mensagens devidas à ocorrênciade eventos. Por exemplo, é possível configurar tratadores de eventos para que, quando ojogador tentar mover o seu sprite por regiões não autorizadas, uma mensagem de erroseja apresentada. Também é permitido que o projetista do jogo defina quantas vidas apersonagem terá durante o jogo.

4.1 Configurações avançadasNeste conjunto avançado de regras, objetiva-se responder às seguintes questões: O

que define um personagem no modelo? Como representar uma localização do jogo na Redede Petri Colorida (RPC)? Como se modelam as transições de estado do jogo na RPC?Como definir uma fase ou mundo? Como são representados os elementos audiovisuais?Essas novas alterações serão explicadas nos próximos tópicos desta seção.

Conforme as regras e convenções já apresentadas, a representação do jogo atravésde RPCs se dá por meio da exploração de suas características estáticas e dinâmicas. Oselementos estáticos, correspondentes às localizações pelas quais os personagens podem selocomover, são representados pelos lugares e transições da rede. Além disso, a posiçãodos lugares e das transições de substituição indica a localização relativa dos elementosgráficos que os representarão na interface gráfica. As fichas distribuídas nos lugares da rede,em seu conjunto, representam o estado global do jogo. Os elementos dinâmicos do jogosão representados pelas inserções e remoções de fichas dos lugares a partir dos disparosdas transições (os eventos), levando o jogo de um estado para outro. Na Figura 36, éapresentado uma Rede de Petri (RP) com um exemplo de jogo muito simples, usado parademonstrar de maneira didática as regras e convenções discutidas nas próximas subseções.

Na Figura 37, é apresentado o jogo renderizado a partir da interpretação dacodificação do modelo apresentado na Figura 36. Para o exemplo mostrado nas figuras 37,41, 42 e 43, foram utilizadas imagens do repositório livre freepik1.

O propósito do jogo modelado nesse exemplo é destruir a casa (lugar A na Figura1 <http://br.freepik.com/>

http://br.freepik.com/

Capítulo 4. Configurações avançadas no CPN Games 49

Figura 36 – Exemplo de Jogo modelado em RPC.

36 e casas da direita nas imagens da Figura 37). Assim, o único personagem do modelo, queé representado pela ficha (2, 1) no lugar A, deverá ir até B, pegar a bomba (disparando atransição correspondente), voltar em A para cumprir o seu intento. A transição DESTRUIRé habilitada somente quando o personagem está na evolução 2 e tal evolução é obtidasomente após a transição PEGAR_BOMBA ser disparada. Quando a casa é destruída,a ficha identificadora do estado do lugar A é modificada para o valor 2, indicando que acasa foi destruída. Os detalhamentos das representações utilizadas são apresentados naspróximas subseções.

4.1.1 Uso de cores estruturadas e representatividade dos campos de uma ficha

Na convenção adotada pelo CPN Games, as fichas são estruturadas com doiscampos inteiros. O primeiro é o identificador (ID) da ficha e define se ela representa umainformação de ambiente, um objeto ou um personagem. O segundo indica um valor queinforma o estado da entidade representada pelo identificador. A Tabela 1 mostra umresumo com a representatividade do parâmetro ID.

Tabela 1 – Regras para criação de fichas representativas de personagem.

Identificador (ID) Representação0 Ambiente1 Objeto2 Player 13 Player 2... ...N Player N-1

As fichas que possuem identificador de ambiente (ID = 0) são usadas para repre-sentar o estado de uma região ou local específico do jogo e nunca são removidas do lugar da


Figura 37 – Evolução da RPC apresentada na Figura 36 e o jogo de concepção simplesgerado à partir desta.

RPC. Por exemplo, o lugar A da rede da Figura 36 representa a casa do personagem, porisso ele contém uma ficha de ambiente com ID = 0. Eventos ocorridos devido à dinâmicado jogo podem mudar o estado da ficha alterando os valores da tupla, por exemplo, de(0, 1) para (0, 2) e, consequentemente, mudando a aparência dessa casa na interface dojogo.

Os objetos (ID = 1) são elementos que podem ser disponibilizados aos personagensem locais do jogo, o que lhes permite “evoluir” ou progredir no jogo. O segundo valor datupla designa o tipo de objeto. É possível, por exemplo, representar uma bomba com atupla (1, 1) e uma moeda com a tupla (1, 2). No exemplo da Figura 36, a ficha (1, 1) nolugar B representa uma bomba.

O identificador 2 ou superior (ID=2,3,...) em um lugar da rede representa umjogador em uma localidade ou região do jogo. No exemplo da Figura 36, a ficha (2, 1) nolugar A representa um jogador. O valor do segundo campo dessa tupla indica a evoluçãodo personagem controlado por aquele jogador. Os personagens podem evoluir a partir daobtenção de itens. Com esta técnica, pode-se modelar uma trama em que um personagemprecisa adquirir algum tipo de bônus para passar por um determinado obstáculo. Por


exemplo, uma regra pode definir a necessidade de possuir uma bomba para destruir umabarreira, permitindo ao jogador progredir para a próxima fase. No exemplo da Figura36, a ficha (2, 1) representa um player com ID = 2, indicando o status do personagemsem nenhum bônus, e a ficha (2, 2) representa o mesmo personagem de posse de umabomba. Na rede usada como exemplo, a mudança de estado do referido jogador se dá pelodisparo da transição PEGAR_BOMBA. Essa condição é verificada para que a transiçãoDESTRUIR seja executada. As três imagens da Figura 37 ilustram, de cima para baixo:o estado inicial do jogo, com o personagem na Casa (A) e a bomba no depósito (B); opersonagem no depósito, recuperando a bomba; e o personagem demolindo a casa.

4.1.2 Configuração gráfica de Personagens, Lugares e Objetos

Na convenção utilizada neste trabalho, além do modelo em RPC, é necessário umarquivo de propriedades para a criação de jogos a partir de RPCs. Este arquivo contém oidentificador das imagens utilizadas para representar os personagens e os locais e regiõesna interface gráfica do jogo. Para isso, utiliza-se um arquivo de texto com a extensão.properties e com o mesmo nome atribuído ao modelo em RPC registrado com a extensão.cpn pelo CPN Tools.

A Figura 38 mostra um exemplo de configuração das imagens usadas para opersonagem de player1 (ID = 2) em quatro etapas do jogo. As aparências em cada etapa sãoindicadas para cada linha usando a nomenclatura nome_do_player.numero_da_etapa

(player1.1, player1.2, ...). O exemplo da Figura 38 está configurado de maneira que opersonagem possua a mesma aparência em todas as etapas. No lado esquerdo da atribuição,o primeiro parâmetro especifica o diretório que contém as figuras de representação dopersonagem, que devem ser gravada no formato PNG. Os parâmetros seguintes, separadospor vírgula, representam a lista de bônus que o personagem possuirá quando mudar paraa referida etapa. Analisando a Figura 38, vê-se que na primeira etapa o player1 não teránenhum bônus. Na segunda, o personagem possui o objeto do tipo 1, na terceira tem umobjeto do tipo 2 e na quarta terá os objetos do tipo 1 e 2. A configuração de objetos seráabordada ao final desta Seção.

Figura 38 – Configuração das propriedades de um player no jogo (.properties).

Os diversos locais e regiões da interface do jogo são representados pelos lugares daRPC. Durante o parsing do arquivo .cpn que contém a representação em RPC do jogo(CARVALHO et al., 2014), a posição de um lugar no modelo indica a posição relativa em


que será renderizada a imagem utilizada para representar esse local na interface gráfica.No exemplo apresentado na Figura 36, indica-se que as imagens correspondentes aos doislugares da rede (A e B) devem ser colocados lado a lado, A à esquerda e B à direita, comomostra o resultado apresentado na Figura 37.

Na convenção adotada, os elementos dinâmicos do jogo são representados na RPCpelas fichas. Portanto, uma ficha com identificador de player em um lugar da RPCrepresenta o estado do jogo no qual um personagem encontra-se no local correspondente.Esse é o caso da rede da Figura 36, em que temos a ficha (2, 1) no lugar A, correspondendo àimagem mais acima da Figura 37, em que se pode ver o personagem na casa correspondente.O disparo de transições simula o movimento do jogador, movendo a ficha com identificadorde player de um lugar de saída para um lugar de entrada na RPC. No exemplo da Figura 36,em cada lugar, pode-se ver uma ficha com identificador 0. Como discutido precedentemente,fichas desse tipo nunca são removidas, mas podem ter o valor do segundo campo da tuplamodificado para representar a mudança de estado e, em consequência, será alterada aaparência do lugar. O disparo da transição T1 move a ficha de player 1 do lugar A para olugar B e o disparo de T2 move esta mesma ficha no sentido oposto. Desta forma, pelaregra modelada, o personagem pode se mover tanto de A para B como de B para A.

Da mesma maneira que se configuram as imagens para os personagens em seusmúltiplos estados, devem ser registradas no arquivo de configurações as imagens querepresentam os diversos estados de cada local do jogo. Utilizando uma representaçãosemelhante à discutida para os players, na Figura 39 é possível observar a definição doscaminhos para o diretório que contém as imagens dos locais do jogo em cada estadopossível. Neste exemplo, são configuradas imagens para dois estados de cada local do jogo,indicando em que local a imagem apropriada está localizada, considerando-se cada estadopossível. Nestes diretórios devem ser gravadas as figuras representativas dos estados doslugares no formato PNG. A primeira linha da Figura 39 indica a localização das figuras querepresentam os estados de valor 1, isto é, as imagens representativas das fichas com valor(0, 1) em cada lugar. Dessa forma, para o modelo apresentado na Figura 36, o diretórioindicado deverá ter as imagens A.png e B.png. De maneira análoga, a segunda linha indicaa localização das figuras que representam o estado de valor 2 de cada lugar, isto é, arepresentação das fichas com valor (0, 2). Na RPC da Figura 36, o lugar A possui doisestados possíveis, conforme pode ser visto nas imagens mais acima e mais abaixo da Figura37.

Figura 39 – Configuração das propriedades dos locais do jogo.

Os objetos representam elementos ou bônus que podem estar presentes em diversos


locais do jogo. Como foi definido na Subseção 4.1.1, as fichas de objetos tem ID igual1 e seus valores indicam o objeto referenciado. Desta forma, no momento da criação dojogo, definem-se arbitrariamente os valores dos objetos. Por exemplo, o valor 1 para umabomba e o valor 2 para uma moeda. Portanto, uma ficha (1, 1) indica que há uma bombano local associado ao lugar que contém esta ficha, da mesma maneira que uma ficha (1, 2)indica a presença de uma moeda. No exemplo da Figura 36, a ficha (1, 1) indica a presençade uma bomba no lugar B. Da mesma maneira que as configurações de lugares, as deobjeto também são definidas simplesmente indicando o caminho do diretório que contémas imagens. Para o exemplo da bomba e da moeda, deve-se ter os arquivos objeto1.png eobjeto2.png, respectivamente. A Figura 40 mostra como definir tal situação no arquivo deconfiguração.

Figura 40 – Configuração das propriedades dos objetos.

4.1.3 Criação de Fases ou Mundos do Jogo

Jogos mais complexos são divididos em várias fases que se desenvolvem em diferentesmundos. Nos próximos exemplos, os modelos em RPC são hierarquizados e as fases do jogosão definidas por sub-redes. Nas redes superiores da hierarquia são modeladas as regrasmais gerais de transição entre as fases do jogo. Estas, por sua vez, são mais detalhadasnas sub-redes.

No exemplo mostrado nos modelos das Figuras 41 e 42, o jogo modelado temum único personagem e o objetivo é arrombar a casa do vizinho (Casa2 ). Para isso seránecessário obter uma ferramenta específica de arrombamento que está guardada no quartodo personagem. Assim, tal personagem deverá entrar em sua casa, ir até o seu quarto epegar a ferramenta. Uma vez que esta ação seja realizada, deverá sair de sua casa e ir atéa casa do vizinho para executar o arrombamento.

Ao lado esquerdo da Figura 41 têm-se a rede que modela a vizinhança (a casa dopersonagem e a casa do vizinho) e as configurações definidas no arquivo de propriedadesdo jogo (.properties). Ao lado direito têm-se o jogo renderizado.

Ao lado esquerdo da Figura 42 é apresentada a rede que modela os detalhes dacasa do personagem (a sala, o quarto e os itens contidos nesta casa) e na direita aparece oresultado da renderização deste modelo. As transições de substituição são utilizadas paradefinir os níveis hierárquicos das redes. Dessa forma, o jogo é dividido em dois mundos ebaseia-se na ideia de exploração, onde o personagem busca itens no jogo que o permitemprogredir.


Figura 41 – Modelagem da vizinhança em RPC.

Figura 42 – Modelagem da Casa1.

4.2 Configuração de NPCEm jogos eletrônicos, é comum existirem personagens exclusivamente controlados

pelo computador. Em geral, tais personagens têm algum papel específico. Eles podem, porexemplo, representar um inimigo, um aliado ou uma fonte de recurso. Personagens comesta característica são conhecidos como Non-Player Character (NPC).

Para definir um personagem como NPC é necessário fazer um conjunto de configura-ções no arquivo .properties. A configuração desse tipo de personagem consiste na definiçãode uma sequência de políticas NPC que representam as suas ações. Cada política NPCdefine um comportamento, podendo ser de três tipos: aleatória, específica ou orientada.

A política aleatória faz com que o personagem NPC execute as ações aleatoriamente,ou, do ponto de vista do modelo RPC, execute transições randomicamente. A políticaespecífica permite que seja definida uma sequência de disparo de transições no modelo RPCpara o NPC. Dessa forma, deve ser estabelecida a sequência exata com que as transiçõesdevem ser disparadas. Por fim, a política orientada permite que seja definido um objetivoa ser alcançado pelo NPC. Assim, o NPC buscar um caminho para chegar até este objetivoe se deslocar até ele.

Com estas três políticas para NPCs, é possível definir o papel de um personagem


não controlável dentro do jogo. Na Figura 43, é apresentado um modelo para um jogo comdois personagens e a imagem do jogo renderizado a partir da interpretação deste modelo.O primeiro (ID = 2) representa o usuário e o segundo (ID = 3) um NPC que faz o papelde um vendedor em uma loja de armas. A ficha com valor (1, 1) é uma moeda (o dinheiropara comprar a arma) e a ficha com valor (1, 2) representa a arma. Assim, uma ficha (N, 2)indica que o personagem N − 1 está com a moeda e a ficha (N, 3) indica que o personagemN − 1 está com a arma. Dessa maneira, o player 1 deve ir até a loja de armas (lugar B)e entregar a moeda (disparar a transição p1_deixar_moeda). Em seguida, o NPC devepegar a moeda (disparar a transição p2_pegar_moeda), ir até o fundo da loja (lugar C ),pegar a arma (disparar a transição p2_pegar_arma), voltar e entregar a arma (disparara transição p2_deixar_arma).

Figura 43 – Exemplo da modelagem de um jogo.

Para definir o comportamento descrito anteriormente para o NPC, é necessáriaapenas uma política NPC específica, indicando a sequência de disparo das transições. NaFigura 44, é apresentada a configuração que deveria ser feita para este propósito.

Figura 44 – Configuração da política NPC para o jogo da Figura 43.

É possível definir mais de uma política NPC, possibilitando que comportamentosmais complexos possam ser obtidos. Por exemplo, um comportamento pode ser configuradocom a seguinte sequência: “ande aleatoriamente até achar o item X; em seguida, desloque-seaté o local que está o personagem N e execute a ação Y”.

Para o jogo da Figura 43, as seguintes regras podem ser definidas para o comporta-mento do NPC: (i) uma política específica para pegar a moeda; (ii) uma política orientadapara chegar ao local em que a arma está; (iii) uma política específica para pegar a arma e,por fim; (iv) uma política aleatória para finalizar as ações restantes. Esta configuração émostrada na Figura 45.

Para a política NPC aleatória é possível especificar uma condição de parada queindica o momento onde a mesma deve ser finalizada. No exemplo anterior, indica-se quea política aleatória deve ser finalizada quando o objeto 2 é encontrado. Por padrão, a


Figura 45 – Sequência de políticas de NPC para comportamentos complexos.

política orientada persegue o objetivo somente no nível (rede) atual do personagem. Paraforçar a busca de caminho entre redes distintas deve se acrescentar o valor ’global’ comoterceiro parâmetro na definição da política orientada.

4.3 AnálisesPara a rede apresentada na Figura 41, a análise é apresentada na Figura 46. Nessa

análise é possível observar que a rede hierárquica não possui laços (No infinite occurrencesequences) e que a rede morre no estado 8. Ao analisar este relatório, o projetista validasua modelagem, pois o objetivo do jogo era, de forma sequencial, pegar o objeto parapoder destruir a casa.

Figura 46 – Relatório de análise da RPC apresentada na Figura 41.


O espaço de estados apresentado na Figura 47 mostra a alternância dos estados darede em uma sequencia e que finaliza no estado 8, o que condiz ao que é apresentado norelatório da Figura 46.

Figura 47 – Espaço de estados da rede apresentada na Figura 41.

Bem similar ao relatório da rede apresentada na Figura 41, a rede apresentada naFigura 43 possui uma sequência de passos para que o jogador obtenha êxito no jogo. Orelatório e o espaço de estados são apresentados nas Figuras 48 e 49, respectivamente.Os relatórios das Figuras 46 e 48 são apresentados mais detalhados no Apêndice B e C,respectivamente.

Figura 48 – Relatório gerado pelo CPN Tools a partir da rede apresentada na Figura 43.

Figura 49 – Espaço de estados da rede apresentada na Figura 43.


4.4 Considerações FinaisNesse capítulo foram apresentadas as configurações avançadas na rede e no arquivo

de configuração para RPC que modelam jogos com NPC, entre elas a configuração dasfichas, as representações gráficas dos elementos do jogo e a criação de fases do jogo. Aconfiguração de NPCs também é abordada, porém é limitada à modelagem de NPCsestáticos, que não se movem dentro do jogo. As análises são apresentadas de forma avalidar a modelagem proposta nos exemplos apresentados durante o capítulo.

59

5 Conclusões e Trabalhos Futuros

Neste trabalho foi apresentado um método de interpretação de modelos de Redes dePetri Coloridas Hierárquicas para geração de jogos eletrônicos. A modelagem permite que oprojetista faça testes e simulações para validar o modelo através de análise formal ainda nafase inicial e utilizando apenas o modelo baseado em RPC Hierárquico. Ainda em fase demodelagem, é possível verificar se há caminhos válidos que levem a personagem do jogo aoslugares previamente estabelecidos ou a armadilhas que o impeçam de progredir no jogo. Aferramenta CPN Games interpreta a rede criada no CPN Tools e então gera o jogo, sem queseja necessário qualquer trabalho de codificação além daquele inerente à própria construçãoda RPC. Esse método de construção permite que pessoas com pouco conhecimento deprogramação concebam seus próprios jogos. Técnicas de programação foram agregadaspara disponibilizar o jogo modelado em dispositivos móveis e em máquinas distintas. Dessaforma, as fichas distintas da rede podem ser controladas por máquinas diferentes coma ajuda de um servidor central. Com o conjunto de ferramentas disponibilizadas nessetrabalho, podemos criar facilmente um leque de jogos de concepção simples com baixocusto, tanto em tempo quanto em orçamento.

Na versão atual, a ferramenta CPN Games permite a criação de jogos multiníveis emultiusuário a partir da instanciação de lugares, transições e sub-redes. Como a ferramentapossui um teor de validação do modelo proposto, objetiva-se aprimorá-la continuamente.Dentre as melhorias estão a representação de diversas propriedades dos personagens atravésdo uso de fichas com estruturas mais complexas e propriedades de condição, temporizaçãoe função.

Outra melhoria em perspectiva está na definição de políticas de navegação deNPCs. A análise desse tipo de modelagem com NPC que se move dentro do jogo ainda nãopode ser realizada com as ferramentas de análise realizada do CPN Tools. Essa limitaçãoderiva do fato de estas políticas estarem descritas fora do modelo da RPC modeladapelo projetista. Futuramente as descrições das políticas serão modeladas juntamente coma RPC, fazendo que seja possível que o comportamento dos NPCs sejam previamenteanalisados juntamente com as ferramentas do CPN Tools.

Os elementos que representam os NPCs e as mídias, que atualmente são representa-dos em um arquivo externo (.properties), serão futuramente incorporados na modelagem.

Também está sendo estudada uma versão que, através de elementos de maior nívelde abstração, dispensa o projetista de conhecer profundamente o formalismo das RPCse de ter habilidades para o uso da interface do CPN Tools, que é considerada complexapela maioria dos usuários. Entretanto, na versão prospectada, embora o projetista possa

Capítulo 5. Conclusões e Trabalhos Futuros 60

modelar sem a necessidade de conhecer a formalização das RPCs, poderá ter acesso aosbenefícios das ferramentas de análise do CPN Tools.

61

Referências

AALST, W. van der; STAHL, C. Modeling Business Processes: A Petri Net-OrientedApproach. [S.l.]: MIT press, 2011. Citado 2 vezes nas páginas 22 e 31.

ARAÚJO, M.; ROQUE, L. Modeling games with petri nets. Breaking New Ground:Innovation in Games, Play, Practice and Theory. DIGRA2009. Londres, Royaume Uni,2009. Citado na página 25.

BARBOSA, R. C. et al. O jogo educacional como recurso digital ea aprendizagemsignificativa de gramática. In: Anais do Simpósio Brasileiro de Informática na Educação.[S.l.: s.n.], 2008. v. 1, n. 1, p. 491–500. Citado na página 16.

BLOW, J. Game development: Harder than you think. Queue, ACM, v. 1, n. 10, p. 28,2004. Citado na página 15.

CARVALHO, V. V. S. et al. A formal method to generate games with multi-level andmulti-user using hierarchical coloured petri nets. XIII Brazilian Symposium on ComputerGames and Digital Entertainment (SBGames 2014), 2014. Citado na página 51.

GERSHENFELD, A.; LOPARCO, M.; BARAJAS, C. Game Plan: The Insider’s Guide toBreaking In and Succeeding in the Computer and Video Game Business. St. Martin’sPress, 2007. ISBN 9781429974271. Disponível em: <http://books.google.ca/books?id=lBo22IJQ52UC>. Citado na página 15.

GRÜBEL, J. M.; BEZ, M. R. Jogos educativos. RENOTE, v. 4, n. 2, 2006. Citado napágina 16.

HWANG, G.-J.; WU, P.-H. Advancements and trends in digital game-based learningresearch: a review of publications in selected journals from 2001 to 2010. British Journalof Educational Technology, Wiley Online Library, v. 43, n. 1, p. E6–E10, 2012. Citado napágina 15.

JENSEN, K.; KRISTENSEN, L. M. Coloured Petri nets: modelling and validation ofconcurrent systems. [S.l.]: Springer, 2009. Citado 4 vezes nas páginas 17, 19, 20 e 21.

KRISTENSEN, L. M. A perspective on explicit state space exploration of coloured petrinets: past, present, and future. In: Applications and Theory of Petri Nets. [S.l.]: Springer,2010. p. 39–42. Citado na página 35.

LEE, Y.-S.; CHO, S.-B. Context-aware petri net for dynamic procedural contentgeneration in role-playing game. Computational Intelligence Magazine, IEEE, IEEE, v. 6,n. 2, p. 16–25, 2011. Citado na página 25.

LEE, Y.-S.; CHO, S.-B. Dynamic quest plot generation using petri net planning. In: ACM.Proceedings of the Workshop at SIGGRAPH Asia. [S.l.], 2012. p. 47–52. Citado na página25.

MANN, B. D. et al. The development of an interactive game-based tool for learningsurgical management algorithms via computer. The American Journal of Surgery, Elsevier,v. 183, n. 3, p. 305–308, 2002. Citado na página 16.

http://books.google.ca/books?id=lBo22IJQ52UC

http://books.google.ca/books?id=lBo22IJQ52UC

Referências 62

MURATA, T. Petri nets: Properties, analysis and applications. Proceedings of the IEEE,IEEE, v. 77, n. 4, p. 541–580, 1989. Citado 3 vezes nas páginas 17, 18 e 19.

ORWANT, J. Eggg: Automated programming for game generation. IBM Systems Journal,v. 39, n. 3.4, p. 782–794, 2000. ISSN 0018-8670. Citado na página 25.

PETERSON, J. L. Petri Net Theory and the Modeling of Systems. Upper Saddle River,NJ, USA: Prentice Hall PTR, 1981. ISBN 0136619835. Citado na página 17.

PETRI, C. A. Kommunikation mit automaten. 1962. Citado na página 17.

PETRILLO, F. et al. What went wrong? a survey of problems in game development.Computers in Entertainment (CIE), ACM, v. 7, n. 1, p. 13, 2009. Citado na página 15.

PIETRUCHINSKI, M. H. et al. Os jogos educativos no contexto do sbie: uma revisãosistemática de literatura. In: Anais do Simpósio Brasileiro de Informática na Educação.[S.l.: s.n.], 2011. v. 1, n. 1. Citado na página 16.

PRENSKY, M. Computer games and learning: Digital game-based learning. Handbook ofcomputer game studies, MIT Press Cambridge, MA, v. 18, p. 97–122, 2005. Citado napágina 15.

SANTOS, S. D.; ROQUE, L. G. Ensaio de reescrita de comportamentos em videojogoscom base no ajuste e computação de modelos de petri net. IX SBGames, 2010. Citado napágina 25.

ULLMAN, J. D. Elements of ML Programming: ML97 Edition. [S.l.]: Prentice Hall, 1998.Citado na página 20.

VECCHIA, R. D.; MALTEMPI, M. V.; WEINGARTEN, T. A construção de jogoseletrônicos ea modelagem matemática na realidade do mundo cibernético. EDUCAÇÃOMATEMÁTICA EM REVISTA–RS, v. 2, n. 14, 2014. Citado na página 16.

Apêndices

64

APÊNDICE A – Relatório - Figura 18

A seguir, é apresentado o relatório relativo à análise da rede da Figura 18.

Statistics

----------------------------------------------------------------------

State Space

Nodes: 48

Arcs: 116

Secs: 0

Status: Full

Scc Graph

Nodes: 4

Arcs: 14

Secs: 0

Boundedness Properties

----------------------------------------------------------------------

Best Integer Bounds

Upper Lower

GameNet'planet1 1 2 0




t5'planet5 1 2 0

t5'planet6 1 2 0

t9'planet7 1 1 0

t9'planet8 1 1 0

Best Upper Multi-set Bounds

GameNet'planet1 1 1`1++ 1`2




t5'planet5 1 1`1++ 1`2

t5'planet6 1 1`1++ 1`2

t9'planet7 1 1`2

t9'planet8 1 1`2

Best Lower Multi-set Bounds

GameNet'planet1 1 empty




t5'planet5 1 empty

t5'planet6 1 empty

t9'planet7 1 empty

t9'planet8 1 empty

Home Properties

----------------------------------------------------------------------

Home Markings

[11]

Liveness Properties

----------------------------------------------------------------------

Dead Markings

[11]

Dead Transition Instances

None

Live Transition Instances

None

Fairness Properties

----------------------------------------------------------------------

Impartial Transition Instances

GameNet't43 1

Fair Transition Instances

None

Just Transition Instances

None

Transition Instances with No Fairness

GameNet't10 1

GameNet't2 1

GameNet't3 1

t5't10 1

t5't7 1

t5't8 1

t9't11 1

t9't12 1

t9't13 1

t9't14 1

67

APÊNDICE B – Relatório - Figura 46


Statistics

------------------------------------------------------------------------

State Space

Nodes: 8

Arcs: 7

Secs: 0

Status: Full

Scc Graph

Nodes: 8

Arcs: 7

Secs: 0


------------------------------------------------------------------------

Best Integer Bounds

Upper Lower

Casa1'Quarto 1 3 1

Casa1'Sala 1 2 1

Vizinhanca'Casa1 1 2 1

Vizinhanca'Casa2 1 2 1


Casa1'Quarto 1 1`(0,1)++

1`(1,1)++

1`(2,1)++

1`(2,2)

Casa1'Sala 1 1`(0,1)++

1`(2,1)++

1`(2,2)

Vizinhanca'Casa1 1 1`(0,1)++

1`(2,1)++

1`(2,2)

Vizinhanca'Casa2 1 1`(0,1)++

1`(0,2)++

1`(2,2)


Casa1'Quarto 1 1`(0,1)

Casa1'Sala 1 1`(0,1)

Vizinhanca'Casa1 1 1`(0,1)

Vizinhanca'Casa2 1 empty

Home Properties

------------------------------------------------------------------------

Home Markings

[8]

Liveness Properties

------------------------------------------------------------------------

Dead Markings

[8]


None


None

Fairness Properties

------------------------------------------------------------------------

No infinite occurrence sequences.

70

APÊNDICE C – Relatório - Figura 48


Statistics

------------------------------------------------------------------------

State Space

Nodes: 9

Arcs: 8

Secs: 0

Status: Full

Scc Graph

Nodes: 9

Arcs: 8

Secs: 0


------------------------------------------------------------------------

Best Integer Bounds

Upper Lower

Exemplo_NPC'A 1 2 1

Exemplo_NPC'B 1 4 2

Exemplo_NPC'C 1 3 1


Exemplo_NPC'A 1 1`(0,1)++ 1`(2,2)

Exemplo_NPC'B 1 1`(0,1)++ 1`(1,1)++ 1`(1,2)++ 1`(2,1)++

1`(2,2)++ 1`(3,1)++ 1`(3,2)++ 1`(3,3)

Exemplo_NPC'C 1 1`(0,1)++ 1`(1,2)++ 1`(3,2)++ 1`(3,3)


Exemplo_NPC'A 1 1`(0,1)

Exemplo_NPC'B 1 1`(0,1)

Exemplo_NPC'C 1 1`(0,1)

Home Properties

------------------------------------------------------------------------

Home Markings

[9]

Liveness Properties

------------------------------------------------------------------------

Dead Markings

[9]


None


None

Fairness Properties

------------------------------------------------------------------------

No infinite occurrence sequences.

Anexos

74

ANEXO A – Artigo - SBGames 2014

O artigo a seguir foi publicado no XIII Simpósio Brasileiro de Jogos e Entreteni-mento Digital (SBGames 2014) e foi condecorado como melhor artigo resumido na trilhada computação.

A Formal Method to Generate Games with Multi-level and Multi-user usingHierarchical Coloured Petri Nets

Vanessa Viana S. CarvalhoUniversidade Federal do Ceara (UFC)

Prof. Msc. Carlos Hairon R. GoncalvesInstituto Federal do Ceara (IFCE)

Joel Cruz SoaresUniversidade Federal do Ceara (UFC)

Felipe Mota BarretoUniversidade Federal do Ceara (UFC)

Prof. Dr. Jose Marques SoaresUniversidade Federal do Ceara (UFC)

Prof. Dr. Giovanni C. BarrosoUniversidade Federal do Ceara (UFC)

Abstract

This paper presents a formal method to the generation of multi-level and multi-user games. Our approach models a multi-usergame containing multiple navigation environments (multi-level) us-ing Hierarchical Coloured Petri Nets, in which are specified all ofthe rules, properties and structures. The created model can be for-mally analysed allowing us to detect deadlocks or dead transitions(invalid paths) and others design problems. The formal analysiscan be made using the CPN Tools. It is presented a tool, calledCPN Games, and a new game in order to validate our method. Thistool allows the user to create, fast and dynamically, simple concep-tion games only using Hierarchical Coloured Petri Nets. Moreover,this tool is able to interpret and execute Hierarchical Coloured PetriNets made in CPN Tools.

Keywords: Hierarchical Coloured Petri Nets, Games, CPN Tools

Author’s Contact:

[email protected]@[email protected]@[email protected]@fisica.ufc.br

1 Introduction

The difficulties inherent in the design of electronic games are thesame that have been discussed in the context of software engineer-ing since the early 1970s. Some of the problems found in the devel-opment of this particular type of software are discussed in [Petrilloet al. 2009].

According to [Blow 2004], programmers do not develop games asthey used to do in the 90’s because the process of a game devel-opment was funny and turned into a complex and difficult thing toimplement (he shows an example of the increasing number of cod-ing components). [Hamann 2003] says that the reason for that isbecause people tend to accumulate a lot of work to do in the dead-line of the project (which he calls Crunch Time), and he also claimsthis is not a particularity of game projects.

Another related problem is the rapid obsolescence due to high re-cycling of the vanguard technologies. The lack of skilled laborfor new technologies and their instability increase the challenges[Petrillo et al. 2009]. It concludes that many of the problems foundcould be minimized if the designers choose to use specialized toolsfor creating games.

Moreover, despite the large variety existing, the productivity toolsto games do not include everything that a game designer needs[Blow 2004]. In general, they are slow to compile, debug and test,making many game elements have to be designed and built fromscratch. So, it is understood that the development of tools that sup-port the development of games is open to new investigations andpropositions.

As a contribution to this area, in this paper is presented a tool thatenables the construction of simple conception games using mod-els in Hierarchical Coloured Petri Nets. It is provided to the de-

signer an environment in which is possible to create new multi-level and multi-user games by modelling. The file coding a modelof Coloured Petri Net (CPN) is processed, and then is generated aninstance of a game, without any coding after the model creation.The locations, paths and rules are established for the game derivedfrom the CPN, which is modelled using CPN Tools1. The XMLcode from a CPN, that is made by CPN Tools, is interpreted bya Java application that builds the game graphical interface to theuser. The user interaction with the graphical interface is obtainedfollowing the rules established during the modelling using the CPNformalisms. Besides the possibility of formal representation of thedynamic and static aspects of a game, the CPN allows the veri-fication and validation of the designed model, using the analysissimulation tools available on CPN Tools.

This paper is organized as follows: in Section 2, it is discussed theuse of Petri Nets in the game development and its correlated works.In Section 3, it is exposed the rules to the game modelling in ourcontext. In Section 4, it is presented the simulation and analysisby a CPN model. In Section 5, it is described an example of agame modelled using the developed tool and how the created modelturned into the game. Finally, in Section 6 is presented the finalconsiderations.

2 Using Petri Nets to Support the Devlop-ment of Electronic Games

The Petri Nets (PN) is a mathematical tool to model systems thathave a graphic representation which consists of arcs and nodes [Mu-rata 1989]. Logical and conceptual errors can be detected usingformal analysis of the structural and behavioural properties, evenin the early steps of the PN modelling. A PN is an abstractionof an original system and can be formally simulated and analysed,allowing the validations and verification of the structural and be-havioural aspects of the net before the implementation of the realsolution [Marranghello 2005].

The PN structure is represented by a set of places, a set of transi-tions, an input function and an output function. Graphically, thebasic structure of a PN are places, arcs and transitions, that are rep-resented by ellipses, directional arcs and rectangles, respectively(Figure 1). The dynamic of a PN is given by the firing of a transi-tion that removes tokens of the input place and put the tokens in thecorresponding output place. The number of tokens removed or putdepends of the arc weight.

Figure 1: Basic structure of a Petri Net

The representation power of a PN is increased with the high levelprogramming language features, that is called High Level PetriNets, in which includes the Coloured Petri Nets (CPN) [Jensen andKristensen 2009]. The CPN allows the representation of many ab-stractions, one of them is a entire net in a single transition, which iscalled substitution transition.

Both ordinary PN and High Level PN have been used to support thedevelopment of electronic games and their multiple features.

1Tool avaiable in http://cpntools.org/

SBC - Proceedings of the SBGames 2014 | ISSN: 2179-2259 Computing Track - Short Papers

XIII SBGames - Porto Alegre - RS - Brazil, November 12th - 14th, 2014 1025

In [Lee and Cho 2011] is proposed a method based in PN to gener-ate little missions or tasks plots to the main characters. The sameauthors present in [Lee and Cho 2012] a tool, called PlotWizard,that gives a support to the development of the game plot. The for-malism based in PN supports only how the characters interact inthe game, not interfering in the graphic properties and the gamecontrolling. The game states mapped to PN are static and qualityrestricted, which decreases the abstraction power of the PN.

In [Araujo and Roque 2009] is presented the modelling of a gameflow in PN, as an alternative more robust to UML and Flowchatmodelling. The authors use as a case study the navigation and map-ping of the coast and sea routes. However, in this approach, there isno generation of automatic coding and of the nets that represent it.

The work of [Santos and Roque 2010] presents an automatic im-plementation of PN models in order to perform dynamic changes inthe game to stimulate the player. The control of each player is ac-complished through a PN and artificial intelligence. PN is adjustedaccording to the agent’s behavior in each session. For agents thatare not controlled by the player, i.e. for the Non-Player Characters(NPCs), the system checks which of the PN arches had more tokenpasses. If the agent succeeds, the section arches over walkways arekept and the other arcs are replaced by arcs chosen in some sort oflottery or are removed. This study presents the modelling of thebehaviour of the elements of the game by RP, but does not allowthe creation or automatic generation of game structure.

Two limitations can be enumarated in the works mentioned above.First, they do not allow representations of multi-level gamesthrough hierarchical Petri nets. To the best of our knowledge, thereis no studies to allow the generation of games in an automated man-ner from models designed in PN.

Among the several tools that allow modelling by Petri Nets, it hasbeen adopted in this work the CPN Tools. The integration of thistool allows the modelling of the structure and behavior of the game,it is possible to perform simulations and formal analysis of the net-work. In the abstraction used to build games using CPN, the recordsdeposited in places represent the game characters and the placesrepresent the regions where the characters can move. Transitionsconstitute the ways on which a character can move from one placeto another, provided they meet the rules of displacement specifiedin the modelling. Transitions substitutions are used to represent thelevel crossings. Using these rules of representation, you can use theCPN model, encoded in XML by CPN Tools, to directly generatethe game. Therefore, it is only necessary to configure the mediathat are associated with the network elements during the construc-tion of its graphical interface. Further details of the use of ColoredPetri Nets for the automatic generation of games are described innext Sections.

3 Rules to Game Modelling

The characters are defined by the tokens configuration of a placeand represent the sprites (characters in movement). Each token rep-resents one sprite. The sprites are associated with a graphic rep-resentation through the numeric identifiers set in the tokens. TheFigure 2 shows an example when two sprites are represented withthe values 1 and 2, identified with the marking 1‘1 ++ 1‘2 (whichmeans that there is a token with the value 1 and other with value 2).The sprites can move through the planets (abstraction to the placesin this game) according to the rules modelled in the CPN. For ex-ample, the CPN of the Figure 2 specifies that the sprites can movein the paths obeying the arrows directions.

The hierarchies from a CPN are specified by substitution transi-tions. These transitions are represented by rectangles with doubleedge, as the transition t5 of the Figure 2. Substitution transitionsrepresents an abstraction level to a sub-net. In the Figure 2, thetransition t5 is the abstraction of the sub-net of the Figure 3.

In this paper is adopted the substitution transitions to configure mul-tiple levels in the game. Thus, when a sprite moves to a substitutiontransition, this sprite is passed to a different domain. This new do-main has a structure which consists of new places and transitionsin which are associated distinct rules from the superior net. In the

Figure 2: Example of a Hierarchical Coloured Petri Net

Figure 3: Sub-net t5 of the transition t5 from the net of the Figure 2

graphical user interface side, when a sprite collides in a substitu-tion transition, means that the phase of the game will change. Thischange of phase automatically change the game scenario image.

4 Simulation and Analysis by the CPNmodel

The formal analysis of a CPN model allows the validation throughthe structural and behavioural properties. The analysis realized withthe CPN Tools can be made by validation (i.e. interactive simula-tion), by verification (i.e. state space analysis), and by performanceanalysis (i.e. monitors simulation) [van der Aalst and Stahl 2011].Furthermore, the analysis report generated by CPN Tools allows theverification of the standard properties of a PN. These report prop-erties can describe if the net is bounded, if the net has any deadmarks (deadlock), if all the transitions are enabled from any mark(liveness, deadlock free), if all marking is reachable from any othermarking (home-marking), and if from any marking is possible toreturn to the home marking (reversible net).

The CPN Tools generates an analysis report, in which is possible toidentify some important properties of the game. For example, it ispossible to check the existence of deadlock in a game plot. Usingthe example of the Figure 2, if the transition t1 is removed, theelements that arrive in the place planet1 will not come back again,which means a deadlock (Figure 4).

Figure 4: Petri Net from the Figure 2, without the transition t1

As the other properties, the deadlock can be viewed by simulationand can be verified by state space analysis of the CPN using theanalysis report generated in the CPN Tools. For the example inthe Figure 4, the CPN Tools generates an analysis report that ispartially shown in the Figure 5. The generated report considersthe initial mark established in the model represented in the Figure 2(1‘2 ++ 1‘1 in the place planet4). In this example, the report showsa deadlock in the marking ”27” (1‘2 ++ 1‘1 in the place planet1 inthe Figure 4). It means that, if the sprites (1‘2 ++ 1‘1) reach theplace planet1, they could never reach other places again.

The Figure 6 shows a state space generated by CPN Tools from thenet of the Figure 4. In this state space is possible to identify thedeadlock state which is highlighted with blue color.



Figure 5: Part of the report generated by CPN Tools

Figure 6: State Space graph generated by CPN Tools from the netof the Figure 4

5 Multi-level and Multi-user Game Project

The possibility to use hierarchical CPN can help the designer withmore options to build the game model. The hierarchy can be mod-elled so that can represent many phases or even a passage to a ful-filment of an extra task.

The Figure 7 shows an interface of the game generated from theCPN of the Figure 2. The model defines the game structure andrules to the sprite movements through the planets. For the examplesof the Figure 7, Figure 9, Figure 13 and the Figure 11, it has beenused used the images from the free repository OpenGameArt2.

Figure 7: Generated game from the net of the Figure 2

The sub-nets are represented in a superior level of a net by substitu-tion transitions. The sprites can move through the multiple levels ofthe game using these transitions. In the game example of the Fig-ure 7, these transitions are represented by a black hole image. Thegame unfolds while the sprites move through the places of the netby the user interaction with the graphical interface. Furthermore,when a sprite collides with a substitution transition, this sprite mi-grates to a different game level, then it is displayed the correspond-ing layout to that level. Rules can be established by modelling, soonly the sprites that had achieved certain properties could changethe level.

The Figure 9 presents a CPN Games vision of two players in thesame machine and in different levels of the game. On the left side,

2Images obtained at http://opengameart.org/

there is a sprite that just came through the black hole of the Figure 7to the following level, that is structured according to the model pre-sented in the net t5 of the Figure 3. On the right side, there is asprite that went through the black hole of the t5 net and arrived onthe t9 net, whose model is represented on the Figure 8.

Figure 8: Sub-net t9 of the transition t9 from the net of the Figure 3

Figure 9: Sprites in two different levels of a game, based on thesub-nets from the Figure 3 and Figure 4

5.1 Changing of the Rules and Structure of theGame by Changing the Model

The model whose the rules and structures were defined can bechanged only using CPN Tools. The new model can be loaded andinterpreted by CPN Games. To illustrate this procedure, when theplace planet3 is removed from the net of the Figure 2, it is obtainedthe net of the Figure 10.

Figure 10: Net from the Figure 2 without the place planet3.

Then, the modified model is loaded in the CPN Games tool andthe image that represents the planet3 will not be shown anymore,as seen in the Figure 11. This procedure can be made without anycode programming.

After realize the modelling or change any existing model, it mustre-execute all the analysis and simulation procedures using the CPNTools in order to validate the new model.

5.2 CPN XML Parsing

The CPN interpretation is realized by a model created in the CPNTools. The generated file by this tool has the extension .cpn, codedfollowing the XML syntactic rules. This file can be analysed by anysyntactic analyser (parser) developed to this language.

The fundamental structures are represented by the elements (tags)place, trans and arc in the generated code of the CPN Tools. In theCPN Games, these structures are implemented in the classes Place,Transition and Arc, respectively. So, in the analysis process, allthe instances of these elements are created and the properties areinitiated according to the attributes extracted from the model.

To identify a sub-net and set different sub-levels of the game, it isnecessary identify the occurrences of the substitution transitions.This is possible when the element <trans> has a <subst> child.Besides, an attribute subpage from the element <subst> has thesub-net identifier that substitutes the transition.



Figure 11: CPN Games of the resulting net of the Figure 10.

In the CPN Games, the Reader class is responsible to the syntacticanalysis of the XML code and to the instantiation of all the elementsthat composes the modelled net to the game.

5.3 Graphical representation of the elements of aCPN model

Besides the building of the model with CPN Tools, in order that agame can be effectively executed by CPN Games, it is necessaryassociate each visible element to a file that contains the representa-tive image. A configuration file with the same name of the file thatcontains the CPN code must be created with the extension .prop-erties (see Figure 12). In this file there must have the relative pathof all the images used in the game. It can have also the relativepaths of the sounds that will be activated in each fired transitionand the representation images of the substitution transitions. Afterthe configuration of the .properties file, the game can be loaded andinitiated.

Figure 12: A file example that defines the graphic and sound prop-erties of the game

5.4 User Interface

To the desktop environment, it was implemented an interface thatcontains all the necessary elements to the graphical representationof the game and the sprites movements by user interaction.

Besides the desktop implementation, it was developed an interfaceto the Android platform. Some aspects about mobile platformsmust deserve some attention, for instance, the display size. In thedesktop version, the camera is fixed and the sprite moves in thescenario that is completely rendered into the graphical interface. Inthis version, only a scenario part is rendered, and the camera mustfollow the sprite during its movement, as shown in Figure 13. Otheraspect that deserve some attention is that in the mobile version theuser can make moves with only one sprite.

Figure 13: Image of the game in a mobile device

It is important to mention the lack of link between the model, thatis independent of platforms, and the interface implementation, thatdepends of a platform. In both cases, different models generate

different games, without any code implementation, making easierthe portability of the games in different devices.

Furthermore, the CPN Games allows the gamers play the samegame in local net. In the future, this communication can be ex-tended to long distance networks. The distribution model used inthis tool is the Server-Client, in which a server centralizes the globalstate of the game. This server can be executed in a mobile deviceor in a desktop. A localization service can identify the servers in alocal network through broadcast messages.

6 Conclusion

This paper presents a method that allows the development of simpleconception games with multiple levels and multiple users only withColoured Petri Net modelling. The model allows the designers toperform tests and simulations before the software implementation.To validate this method, it was developed a tool, called CPN Games.This tool allows the user develop simple conception games, like thegame described in this paper. The CPN Games was implemented intwo versions of graphical user interface. One is the desktop version,where the user interaction is made by the keyboard, and the otherversion is to mobile (Android), where the user interaction can bemade by touchscreen or by accelerometer. Regardless of the kindof user interface, it is not necessary any additional code program-ming after the building and analysis of the model. This methodallows people with little programming knowledge to develop theirown games. With the tools described in this paper, it is possibleeasily develop a range of simple conception games with low costand high productive.

References

ARAUJO, M., AND ROQUE, L. 2009. Modeling games with petrinets. Breaking New Ground: Innovation in Games, Play, Prac-tice and Theory. DIGRA2009. Londres, Royaume Uni.

BLOW, J. 2004. Game development: Harder than you think. Queue1, 10, 28.

HAMANN, W., 2003. Goodbye postmortems, hello critical stageanalysis.

JENSEN, K., AND KRISTENSEN, L. M. 2009. Coloured Petri nets:modelling and validation of concurrent systems. Springer.

LEE, Y.-S., AND CHO, S.-B. 2011. Context-aware petri net for dy-namic procedural content generation in role-playing game. Com-putational Intelligence Magazine, IEEE 6, 2, 16–25.

LEE, Y.-S., AND CHO, S.-B. 2012. Dynamic quest plot genera-tion using petri net planning. In Proceedings of the Workshop atSIGGRAPH Asia, ACM, 47–52.

MARRANGHELLO, N. 2005. Redes de petri: Conceitos eaplicacoes. Sao Paulo: DCCE/IBILCE/UNESP.

MURATA, T. 1989. Petri nets: Properties, analysis and applications.Proceedings of the IEEE 77, 4, 541–580.

PETRILLO, F., PIMENTA, M., TRINDADE, F., AND DIETRICH,C. 2009. What went wrong? a survey of problems in gamedevelopment. Computers in Entertainment (CIE) 7, 1, 13.

SANTOS, S. D., AND ROQUE, L. G. 2010. Ensaio de reescrita decomportamentos em videojogos com base no ajuste e computaode modelos de petri net. IX SBGames.

VAN DER AALST, W., AND STAHL, C. 2011. Modeling BusinessProcesses: A Petri Net-Oriented Approach. MIT press.



79

ANEXO B – Artigo - SBIE 2014

O artigo a seguir foi publicado no 25o Simpósio Brasileiro de Informática naEducação (SBIE 2014).

Criacao de Jogos Didaticos de Perguntas e Respostas por meiode Modelagem em Redes de Petri Coloridas Hierarquicas

Vanessa Viana S. Carvalho1, Carlos Hairon R. Goncalves2, Joel Cruz Soares1,Felipe Mota Barreto1, Jose Marques Soares1, Giovanni C. Barroso1

1Universidade Federal do Ceara (UFC)

2Instituto Federal do Ceara (IFCE)

[email protected], [email protected], [email protected]


Abstract. This paper presents a method to create question-and-answer gamesonly using Hierarchical Coloured Petri Nets. The rules, properties and struc-tures are specified in the modelling that are automatically instantiated from theinterpretation of the model. The created model can be formally analysed andall the inconsistencies and mistakes can be identified. To validate this method,it is shown the CPN Quiz tool and a didactic example of a question-and-answergame made by this tool.

Resumo. Este trabalho apresenta um metodo para a criacao de jogos de per-guntas e respostas exclusivamente por meio de modelagem em de Redes de PetriColorias Hierarquicas. As regras, propriedades e estruturas do jogo sao especi-ficadas na modelagem e automaticamente instanciadas a partir da interpretacaodo modelo. O modelo criado pode ser analisado formalmente e todas as incon-sistencias e erros podem ser identificados. Para validar o metodo, e apresen-tada a ferramenta CPN Quiz e um exemplo didatico de um jogo de perguntas erespostas criado por essa ferramenta.

1. Introducao

Os jogos educativos vem sendo progressivamente incluıdos no processo daeducacao [Prensky 2005], [Hwang and Wu 2012]. Varios sao os exemplos de jo-gos dessa natureza [Barbosa et al. 2008], [Grubel and Bez 2006], [Mann et al. 2002],[Dalla Vecchia et al. 2014] e [Pietruchinski et al. 2011]. O jogo Refraction1 e um exem-plo de um jogo educativo que foi financiado pela Bill & Melinda Gates Foundation2.Porem, as dificuldades existentes na criacao de um jogo eletronico sao as mesmasexistentes na criacao de qualquer outro software. Tais problematicas vem sendo de-batidas no contexto da Engenharia de Software desde o inıcio da decada de 1970[Petrillo et al. 2009]. Entre as dificuldades encontradas nessa area, de maneira ge-ral, percebe-se que a rapida obsolescencia de ferramentas e tecnologias de desenvolvi-mento. Uma maneira de minimizar tal problema e o reuso de estruturas que permi-tam ao desenvolvedor o mınimo ou mesmo nenhuma programacao, quando possıvel.

1http://centerforgamescience.org/portfolio/refraction/2http://www.gatesfoundation.org/

[Resnick et al. 2009] e [Torrente et al. 2010] sao exemplos de ferramentas que permitemo desenvolvimento de jogos com as caracterısticas mencionadas acima.

Neste trabalho e apresentada uma ferramenta que viabiliza a concepcao econstrucao de jogos de perguntas e respostas, a partir de modelos em Redes de PetriColoridas (RPC). Com a possibilidade de modelar hierarquicamente a RPC, o designerdo jogo pode criar jogos de Perguntas e Respostas em que o usuario vai avancando nojogo de acordo com o nıvel modelado. O arquivo de codificacao do modelo em RPC eprocessado e gera uma instancia do jogo, nao sendo necessaria qualquer codificacao adi-cional apos a construcao do modelo. As localidades, caminhos e regras estabelecidas parao jogo derivam das caracterısticas da RPC, que e modelada com o uso da ferramenta CPNTools3.

Este trabalho esta estruturado da seguinte maneira: na Secao 2 sao introduzidosos conceitos basicos, tais como Redes de Petri Coloridas e Hierarquicas e os trabalhosrelacionados. Na Secao 3 e apresentado o as regras de modelagem. Na Secao 4 saointroduzidos conceitos de RP hierarquica para modelagem de multinıveis. Na Secao 5sao apresentadas as consideracoes finais.

2. Uso de Redes de Petri para apoio a concepcao de jogos eletronicosAs Redes de Petri (RP) constituem uma ferramenta matematica para modelagem de siste-mas, possuindo uma representacao grafica formada por arcos e nos [Murata 1989]. Gra-ficamente, a estrutura basica das Redes de Petri (RP) sao os lugares, arcos e transicoes,que sao representados por elipses, arcos direcionais e retangulos, respectivamente. Adinamica de uma RP se da pelo disparo de uma transicao que remove fichas dos lugaresde entrada e deposita fichas nos lugares de saıda.

As RPs vem sendo empregadas como instrumento de suporte ao desenvolvi-mento de jogos eletronicos em suas multiplas caracterısticas. Alguns exemplos saoapresentados em [Lee and Cho 2011], [Lee and Cho 2012], [Araujo and Roque 2009] e[Santos and Roque 2010]. Porem, eles nao permitem representacoes de jogos multinıvelpor meio de Redes de Petri hierarquicas. Alem disso, nao foram encontrados trabalhosque permitam a geracao de jogos de maneira automatizada a partir de modelos concebidosem RP.

Dentre as diversas ferramentas que permitem a modelagem por Redes de Petri4, foiadotada neste trabalho a ferramenta CPN Tools. A integracao dessa ferramenta permite amodelagem da estrutura e do comportamento do jogo, sendo possıvel realizar simulacoese a analise formal da rede.

3. Regras para modelagem de jogosAs personagens do jogo sao definidas pela configuracao das fichas, que sao colocadas noslugares e representam os sprites (personagens em movimento). Cada ficha representa umunico sprite. Os sprites sao associados a uma representacao grafica atraves de identifica-dores numericos configurados nas fichas. A imagem A da Figura 1 apresenta um exemploem que uma personagem e representada pelo valor inteiro 1, identificado pela marcacao

3Ferramenta disponıvel em http://cpntools.org/4Lista disponıvel em http://www.informatik.uni-hamburg.de/TGI/PetriNets/tools/quick.html

1‘1 (significando uma ficha com o valor 1). A personagem pode se deslocar entre os ca-minhos (abstracao feita para os lugares neste exemplo de jogo) de acordo com as regrasmodeladas na RPC. Por exemplo, a RPC da imagem A da Figura 1 especificam que apersonagem pode percorrer os caminhos nos sentidos das setas. A imagem C da Figura1 apresenta a interface do jogo gerado a partir da RPC da imagem A da Figura 1. O jogomodelado define a estrutura do jogo e as regras para o deslocamento de personagens porvarios lugares.

Figura 1. Na imagem A, exemplo de uma Rede de Petri Colorida Hierarquica. Naimagem B, sub-rede Pergunta11, que processa a transicao de substituicao tema1da rede da imagem A. Na imagem C, e apresentado o jogo gerado a partir da rededa imagem A.

As hierarquias em uma RPC sao especificadas por meio de transicoes desubstituicao. Estas sao representadas por retangulos de borda dupla, como a transicaoidentificada por tema1, tema2 e tema3 da imagem A da Figura 1. Transicoes desubstituicao representam um nıvel de abstracao para uma sub-rede. No exemplo apresen-tado, a transicao tema1 da imagem A da Figura 1 e a abstracao da sub-rede apresentadana imagem B da Figura 1.

E adotado as transicoes de substituicao para configurar multiplos nıveis no jogo.Dessa maneira, ao deslocar um sprite para uma transicao de substituicao, a personagem etransferida para outro domınio, em que a estrutura de deslocamento e constituıda por no-vos lugares e transicoes que sao associados por regras distintas aquelas do nıvel anterior.Do ponto de vista da interface grafica, o deslocamento para uma transicao de substituicaoimplica na mudanca da fase do jogo, com consequente modificacao da imagem do cenario.

4. Projeto de Jogos Multinıveis de Perguntas e Respostas

A possibilidade de usar uma RPC hierarquica pode ajudar o projetista com mais opcoespara realizar a modelagem do jogo. A hierarquia pode ser modelada de forma que poderepresentar varias fases ou ate uma passagem para o cumprimento de uma tarefa extra.

Para a construcao do jogo, cada pergunta e cada resposta devem correspondera uma imagem. Um exemplo pode ser visto na Figura 2, onde para a transicao desubstituicao tema2 da imagem A da Figura 1, foi utilizada a imagem A da Figura 2, epara o lugar de entrada Pergunta1.1 foi utilizada a imagem B da Figura 2. Essas imagensserao interpretadas pela ferramenta como especificado no modelo.

Sendo as sub-redes representadas em uma rede de nıvel superior por transicoesde substituicao, a personagem pode se deslocar pelos multiplos nıveis do jogo atraves dautilizacao de portais especıficos. No exemplo de jogo apresentado na imagem C da Figura1, esses portais sao representados por uma imagem de um tema. O jogo se desenvolve demaneira que, a partir de interacoes do usuario com a interface grafica, o sprite se movi-menta entre os diversos lugares existentes na rede. Alem disso, ao fazer o sprite colidir

com a representacao de um portal, migra-se para um nıvel diferente do jogo, momentoem que e apresentado ao usuario o layout correspondente aquele nıvel. Regras podemser estabelecidas via modelagem de maneira que apenas os sprites que tenham alcancadodeterminadas propriedades possam mudar de nıvel.

Figura 2. A imagem A substitui uma transicao de substituicao (tema2). A imagemB substitui um lugar de entrada (Pergunta2.1). Na imagem C, rede da imagemA da Figura 1 sem os lugares e as transicoes de retorno. Na imagem D, rededa imagem C sem a transicao tema1 e o lugar path1. Na imagem E, CPN Quizapresentando a geracao do jogo relativo a rede.

O modelo em que foram definidas as regras e a estrutura do jogo pode ser mo-dificado exclusivamente a partir do CPN Tools. O novo modelo pode, entao, ser carre-gado e interpretado pelo CPN Quiz. Para exemplificar esse procedimento, ao retirar-se atransicao de substituicao tema1, a transicao t1 e o lugar com o nome path1 da imagem Cda rede da Figura 2, obtem-se a rede apresentada na imagem D da Figura 2. Em seguida,carregando-se o modelo modificado na ferramenta CPN Quiz, a imagem que representaa transicao e a imagem que representa o lugar retirado do modelo nao serao mais apre-sentadas, como e apresentado na imagem E da Figura 2, sem que seja necessaria umalinha sequer de programacao. Apos realizar a modelagem ou fazer qualquer alteracao emmodelos existentes, devem-se reexecutar os procedimentos de analises e simulacoes pormeio da ferramenta CPN Tools para validacao do novo modelo.

5. Conclusoes

Neste trabalho e apresentado um metodo que permite a construcao de jogos de pergun-tas e respostas com multiplos nıveis exclusivamente por modelagem em RPC. Modelospermitem que o projetista faca testes e simulacoes antes da implementacao efetiva do soft-ware. No CPN Quiz, nao e necessaria qualquer atividade de programacao adicional aposa construcao e analise do modelo. Dessa maneira, esse metodo de construcao permite quepessoas com pouco conhecimento de programacao concebam seus proprios jogos. Como conjunto de ferramentas disponibilizadas nesse trabalho, e possıvel criar facilmente umleque de jogos educacionais de concepcao simples com baixo custo e alta produtividade.

Agradecimentos

Ao CNPq - Conselho Nacional de Desenvolvimento Cientıfico e Tecnologico, instituicaocientıfica da maior respeitabilidade no meio academico brasileiro, o nosso agradecimentopela parceria na realizacao deste artigo.

Referencias

Araujo, M. and Roque, L. (2009). Modeling games with petri nets. Breaking New Ground:Innovation in Games, Play, Practice and Theory. DIGRA2009. Londres, Royaume Uni.

Barbosa, R. C., Tavares, R., Santos, J. N. d., Rodrigues, G. L., and Andrade, M. (2008). Ojogo educacional como recurso digital ea aprendizagem significativa de gramatica. InAnais do Simposio Brasileiro de Informatica na Educacao, volume 1, pages 491–500.

Dalla Vecchia, R., Maltempi, M. V., and Weingarten, T. (2014). A construcao dejogos eletronicos ea modelagem matematica na realidade do mundo cibernetico.EDUCACAO MATEMATICA EM REVISTA–RS, 2(14).

Grubel, J. M. and Bez, M. R. (2006). Jogos educativos. RENOTE, 4(2).

Hwang, G.-J. and Wu, P.-H. (2012). Advancements and trends in digital game-basedlearning research: a review of publications in selected journals from 2001 to 2010.British Journal of Educational Technology, 43(1):E6–E10.

Jensen, K. and Kristensen, L. M. (2009). Coloured Petri nets: modelling and validationof concurrent systems. Springer.

Lee, Y.-S. and Cho, S.-B. (2011). Context-aware petri net for dynamic procedural con-tent generation in role-playing game. Computational Intelligence Magazine, IEEE,6(2):16–25.

Lee, Y.-S. and Cho, S.-B. (2012). Dynamic quest plot generation using petri net planning.In Proceedings of the Workshop at SIGGRAPH Asia, pages 47–52. ACM.

Mann, B. D., Eidelson, B. M., Fukuchi, S. G., Nissman, S. A., Robertson, S., and Jardines,L. (2002). The development of an interactive game-based tool for learning surgicalmanagement algorithms via computer. The American Journal of Surgery, 183(3):305–308.

Murata, T. (1989). Petri nets: Properties, analysis and applications. Proceedings of theIEEE, 77(4):541–580.

Petrillo, F., Pimenta, M., Trindade, F., and Dietrich, C. (2009). What went wrong? asurvey of problems in game development. Computers in Entertainment (CIE), 7(1):13.

Pietruchinski, M. H., Coelho Neto, J., Malucelli, A., and Reinehr, S. (2011). Os jogoseducativos no contexto do sbie: uma revisao sistematica de literatura. In Anais doSimposio Brasileiro de Informatica na Educacao, volume 1.

Prensky, M. (2005). Computer games and learning: Digital game-based learning. Hand-book of computer game studies, 18:97–122.

Resnick, M., Maloney, J., Monroy-Hernandez, A., Rusk, N., Eastmond, E., Brennan, K.,Millner, A., Rosenbaum, E., Silver, J., Silverman, B., et al. (2009). Scratch: program-ming for all. Communications of the ACM, 52(11):60–67.

Santos, S. D. and Roque, L. G. (2010). Ensaio de reescrita de comportamentos em vide-ojogos com base no ajuste e computacao de modelos de petri net. IX SBGames.

Torrente, J., Del Blanco, A., Marchiori, E. J., Moreno-Ger, P., and Fernandez-Manjon, B.(2010). < e-adventure>: Introducing educational games in the learning process. InEducation Engineering (EDUCON), 2010 IEEE, pages 1121–1126. IEEE.

85

ANEXO C – Artigo - EPOCA 2014

O artigo a seguir foi publicado na 7a A Escola POtiguar de Computação e suasAplicações (EPOCA 2014).

Petri Game: Uma Ferramenta de Interpretacao de Jogos emDispositivos Moveis Modelada por Redes de Petri Coloridas

Vanessa Viana S. Carvalho1, Felipe Mota Barreto1, Joel Cruz Soares1,Carlos Hairon R. Goncalves2, Jose Marques Soares1, Giovanni C. Barroso1

1Universidade Federal do Ceara (UFC)

2Instituto Federal do Ceara (IFCE)



Abstract. This paper presents a tool, called Petri Game, that interprets modelsin Coloured Petri Nets and generates games to mobile devices. This tool offersa high level interface, making the hardware components more transparent, andusing pre-developed components, emphasizing the software reuse.

Resumo. Este trabalho apresenta uma ferramenta, chamada Petri Game, queinterpreta modelos em Redes de Petri Coloridas e gera jogos para dispositivosmoveis. Essa ferramenta oferece uma interface de alto nıvel, abstraindo aomaximo de aspectos de hardware, e utiliza um conjunto de componentes ja de-senvolvidos, enfatizando a reutilizacao de software.

1. Introducao

Jogos computacionais sao exemplos de sistemas de software que atraem milhoes de pes-soas e movimentam bilhoes de dolares ao ano [Battaiola et al. 2002]. [Bianchini 2005]define esta classe de jogos como sendo qualquer jogo que pode ser simulado emum dispositivo computacional, seja ele analogico ou digital, mecanico ou eletronico.O mundo dos jogos para plataformas moveis atrai ainda mais atencao. Segundo[Ahmed and Aule 2011], o mercado de jogos para o cenario movel vem se expandindorapidamente desde a introducao dos smartphones com as plataformas iOS e Android. Jo-gos para plataformas moveis deixaram de ser apenas um passatempo e tıtulos cada vezmais complexos vem sendo desenvolvidos.

Com o mercado de jogos se tornando cada vez mais competitivo, caracterısticascomo a minimizacao do tempo de desenvolvimento e a alta produtividade aumentaram suaimportancia. Isto requereu a utilizacao de ferramentas para desenvolvimento intuitivas ecom um nıvel de abstracao elevado.

Este trabalho se contextualiza no desenvolvimento de uma ferramenta que permitaa criacao de jogos para a plataforma Android a partir de um modelo em Rede de PetriColorida (RPC) [Jensen 1994]. Essa ferramenta interpreta um modelo em RPC para ainstanciacao de um jogo. Isso permite que o desenvolvedor o construa apenas por meiode uma modelagem de alto nıvel e elimine qualquer necessidade de programacao.

2. Tecnologias e suas Aplicacoes

2.1. Redes de Petri Coloridas

As Redes de Petri Coloridas (RPCs) sao uma linguagem grafica para construir modelosde sistemas a eventos discretos e analisar suas propriedades. Essa linguagem combinaas capacidades das Redes de Petri (RPs) com a capacidade de uma programacao de altonıvel. A vantagem das RPCs sobre outras RPs e a sua habilidade de modelar sistemascomplexos e prover modelos com alto grau de abstracao e melhor representacao grafica[Jensen and Kristensen 2009].

A estrutura basica das Redes de Petri (RP) sao os lugares, arcos e transicoes,que sao representados graficamente por elipses, arcos direcionais e retangulos, respecti-vamente. Os lugares representam o estado do sistema modelado. Cada lugar pode sermarcado com uma ou mais fichas, e cada ficha contem seus conjuntos de dados. Essesdados sao chamados de cor da ficha. O numero de fichas e suas cores representam o es-tado atual do sistema. Isto e chamado marcacao do modelo RPC. As fichas em um lugarespecıfico representam a marcacao deste lugar.

Os disparos das transicoes representam os eventos que podem ocorrer no sistema.Quando uma transicao ocorre, ela remove fichas de seus lugares de entrada e adicionafichas aos seus lugares de saıda. As fichas removidas de seus lugares de entrada e adi-cionadas aos seus lugares de saıda sao determinadas por meios das expressoes que rotulamos arcos. Tambem e permitido que transicoes possuam uma guarda. Esta e uma expressaobooleana: quando uma guarda e verdadeira, o evento pode ocorrer ou, caso contrario, oevento fica desabilitado.

Erros logicos e conceituais podem ser detectados a partir da analise das pro-priedades comportamentais e estruturais de um modelo em RPC, a partir de metodosde validacao formal, ainda na fase de analise do sistema alvo. Isso evita que erros sepropaguem para fases avancadas de implementacao.

As RPs vem sendo empregadas como instrumento de suporte ao desenvolvi-mento de jogos eletronicos em suas multiplas caracterısticas [Lee and Cho 2011],[Lee and Cho 2012], [Araujo and Roque 2009] e [Santos and Roque 2010]. Porem, elesnao permitem representacoes de jogos multinıvel por meio de Redes de Petri hierarquicas.Alem disso, nao foram encontrados trabalhos que permitam a geracao de jogos para dis-positivos moveis de maneira automatizada a partir de modelos concebidos em RP ou RPC.

Dentre as diversas ferramentas que permitem a modelagem por Redes de Petri1, foiadotada neste trabalho a ferramenta CPN Tools. A integracao dessa ferramenta permite amodelagem da estrutura e do comportamento do jogo, sendo possıvel realizar simulacoese a analise formal da rede.

2.2. Plataforma Android

Android e uma plataforma de software livre desenvolvida para dispositivos moveis queinclui um sistema operacional, um middleware e algumas aplicacoes essenciais. Asaplicacoes sao compostas por quatro componentes basicos: Activities, Services, Broad-cast Receivers e Content Providers [Chen 2010].

1Lista disponıvel em http://www.informatik.uni-hamburg.de/TGI/PetriNets/tools/quick.html

Uma Activity representa uma unica tela composta por elementos visuais, chama-dos Views, que respondem a eventos do usuario e podem retornar algum valor para outraActivity. Um Service e uma thread executada em background que nao possui nenhumainterface grafica. Uma Activity pode iniciar um Service ou se conectar a um ja existente.Os Broadcast Receivers sao responsaveis por capturar eventos externos, como mudancano fuso horario, termino do download de um arquivo, ou ate mesmo evento de boot dosistema. Aplicacoes podem ter um numero ilimitado de Broadcast Receivers. Os ContentProviders sao utilizados para prover a troca de dados entre aplicacoes.

Um grande atrativo para a plataforma Android em relacao as outras existentes domercado (e.g. iOS) e ser open-source. A maior parte do codigo esta licenciado pelaApache Licence 2. Esta licenca e bem menos restritiva, quando comparada as outras desoftware livre, tais como GNU General Public Licence (GPL). Qualquer usuario e livrepara usar o codigo fonte e criar o seu proprio sistema, podendo ate ser proprietario.

3. Convencoes para Modelagem de Jogos de Concepcao Simples por Redesde Petri

Na convencao adotada baseada na estrutura basica das Redes de Petri, lugares representamas regioes para as quais os personagens podem se deslocar. As transicoes configuramos caminhos pelos quais uma personagem pode migrar de um lugar para outro, desdeque obedecam as regras de deslocamento. As imagens dos lugares sao posicionadas nainterface do jogo de acordo com a posicao modelada na ferramenta CPN Tools.

Os personagens sao definidos pela configuracao das fichas que sao colocadas noslugares. As fichas representam os sprites (personagens em movimento), sendo uma ficharepresentativa de um unico sprite. Os sprites sao associados a uma representacao graficaatraves de identificadores numericos configurados nas fichas. A Figura 1 apresenta umexemplo em que dois personagens sao representados pelos valores inteiros 1 e 2, iden-tificados pela marcacao 1‘1 ++ 1‘2 (significando uma ficha com o valor 1 e uma fichacom o valor 2 no lugar planet4). Os personagens podem se deslocar entre os planetas(abstracao feita para os lugares neste exemplo de jogo) de acordo com as regras mod-eladas na RPC. Por exemplo, a RPC da Figura 1 especifica que as personagens podempercorrer os planetas nos seguintes sentidos: planet1 para planet2, planet2 para planet3,planet3 para planet4, planet4 para planet1, planet2 para planet4 e planet4 para planet3.

As hierarquias em uma RPC sao especificadas por meio de transicoes desubstituicao. Estas sao representadas por retangulos de borda dupla, como a transicaoidentificada por t5 da Figura 1. Transicoes de substituicao representam um nıvel deabstracao para uma sub-rede. No exemplo apresentado, a transicao t5 da Figura 1 e aabstracao da sub-rede apresentada na Figura 2 que, por sua vez, possui uma transicao desubstituicao t9, cuja sub-rede e apresentada na Figura 3.

Adotaram-se as transicoes de substituicao para configurar multiplos nıveis nojogo. Dessa maneira, ao ser disparada uma transicao de substituicao, o personagem etransferido para outro domınio, em que a estrutura de deslocamento e constituıda pornovos lugares e transicoes, que sao associados por regras distintas aquelas do nıvel ante-rior. Do ponto de vista da interface grafica, o disparo de uma transicao de substituicaoimplica na mudanca da fase do jogo, com consequente modificacao da imagem de fundo.

Figure 1. Exemplo de uma Rede de Petri Colorida e Hierarquica.

Figure 2. Sub-rede t5 da transicao t5 da rede da Figura 1.

4. O Petri Game e seus ComponentesO sistema desenvolvido e uma aplicacao que implementa as convencoes especificadas naSecao 3 e que torna possıvel a criacao jogos multinıveis e multiusuarios. O processo deconstrucao de um novo jogo a partir de modelagem por Rede de Petri Colorida (RPC) noPetri Game e dividido em varias etapas. Cada componente do sistema implementa umadessas etapas, de forma que o conjunto desses componentes e mostrada na Figura 4.

O componente Game Loader e responsavel por criar uma representacao completados atributos do jogo modelado. A partir de um arquivo que contem o XML que repre-senta o modelo em Rede de Petri Colorida e de outro arquivo com informacoes adicionaisda configuracao, e criada uma abstracao de mais alto nıvel. Esta sera utilizada pelosdemais componentes do sistema.

Apos o parsing do modelo em RPC e o processamento do arquivo de configuracao,o Game Loader carrega os recursos do jogo e estabelece a conexao com um servidorexistente. O componente Assets Loader carrega na memoria todos os recursos graficos ede audio, o que permite uma execucao mais rapida do jogo. No entanto, em contrapartidaisso aumenta o consumo de memoria. Ja o componente Communication e responsavelpela comunicacao entre os componentes distribuıdos do jogo, iniciando pela instanciacaode um servidor ou pela conexao a um que ja esteja disponıvel. O Communication tambeme o componente responsavel pelo envio de mensagens relativas aos eventos gerados pelasinteracoes dos usuarios, alem da manutencao do estado global consistente do ambiente

Figure 3. Sub-rede t9 da transicao t9 da rede da Figura 2.

Figure 4. Visao Geral do Sistema.

distribuıdo.

O Game Updater e responsavel por atualizar os objetos presentes no jogo, comojogadores, imagens e lugares. Essas atualizacoes podem ser ocasionadas por eventoslocais do usuario, por exemplo, deslocamento do sprite. Nesse caso, o Input Handler equem gerencia este processo. Outra situacao e que a atualizacao tenha sido gerada por umevento de outro jogador da rede, atraves do componente Communication.

Por fim, o Game Renderer gerencia a exibicao do jogo na tela do dispositivo.Funcoes como posicionamento de imagens na tela, animacoes, movimentacao de person-agens sao de responsabilidade deste componente.

4.1. Parsing e Interpretacao do Modelo em RPC

O modelo deve ser capaz de representar todos os atributos do jogo. No Petri Game, doismodelos diferentes geram dois jogos diferentes, sem a necessidade de nenhuma alteracaoadicional no codigo em Java que implementa a logica e/ou a interface do jogo.

O arquivo XML que contem a codificacao do modelo em Rede de Petri Coloridae o arquivo de configuracao formam o conjunto de entrada para a geracao da instancia deum jogo. A Figura 5 apresenta uma visao geral deste componente.

O objetivo do componente Game Loader e criar um novo jogo a partir das pro-priedades e do arquivo XML de entrada e fornecer a interface para interacao do usuario

Figure 5. Estrutura do Game Loader.

e movimentacao da personagem. Todos os outros componentes se utilizam deste modelopara suas diversas funcoes.

4.2. ComunicacaoO Petri Game utiliza uma arquitetura centralizada, em que um servidor age como inter-mediario na replicacao do estado do jogo. Entretanto, a instanciacao de servidores podeser realizada dinamicamente.

A descoberta de servidores locais e realizada atraves de mensagens broadcast como uso de um protocolo especificado para a aplicacao. Sempre que um cliente e acionado,envia uma solicitacao do tipo Server Ip Request por broadcast e aguarda respostas deum eventual servidor que esteja ativo na rede. Um servidor local ativo espera pacotesUDP em uma porta conhecida, interpreta seu conteudo e envia uma resposta contendoseu endereco de IP para o no solicitante. E definido um time out para essa operacao, poise possıvel que nao exista nenhum servidor disponıvel na rede local. Caso ocorra o timeout, o proprio cliente instancia um servidor localmente para executar a aplicacao. Esteservidor podera, entao, ser compartilhado com outros jogadores na mesma rede local.

5. Interface do Petri GameAo iniciar a aplicacao Petri Game, uma tela de apresentacao e renderizada junto a umapequena animacao de fade in e fade out.

Em seguida, o usuario escolhe em uma lista o jogo que deseja executar (o que cor-responde a um modelo em RPC). Uma pre-visualizacao do jogo e apresentada ao lado decada item da lista. Apos a escolha do jogo, os recursos graficos e sonoros sao carregadospara renderizacao da interface grafica e a conexao com o servidor e estabelecida. Duranteeste processo, em que tambem e realizado o parsing da RPC, uma animacao indica aousuario que esta sendo feito o carregamento do jogo.

Na Imagem A da Figura 6 e mostrada a renderizacao resultante do processamentoda RPC apresentada na Figura 1. As imagens usadas para os elementos do jogo foramobtidas do repositorio livre OpenGameArt2.

Cada elemento contido no modelo em RPC e interpretado como um objeto da redeprincipal. A conexao de um jogador e a sua dinamica ao longo do jogo e percebida pelo

2Imagens dos planetas obtidas em http://opengameart.org/content/20-planet-sprites e imagem do spriteobtida em http://opengameart.org/content/rocket

movimento do seu sprite entre os lugares especificados na rede que sao representados porimagens apropriadas na interface grafica. A hierarquia do modelo, que define a mudancade nıvel na interface grafica, e representada por uma imagem que sugere essa transicao.No exemplo da imagem A da Figura 6, essa mudanca de nıvel e representada pelo buraconegro que fica entre os quatro planetas apresentados. Ao atingir o buraco negro, o jogadorpassa a uma nova fase, exibindo outros elementos. No caso do exemplo apresentado naFigura 6, ao se atingir o buraco negro da Imagem A, chega-se ao nıvel apresentado naimagem B, em que se percebe um espaco contendo dois outros planetas.

Figure 6. Imagem A, jogo gerado a partir da RPC da Figura 1. Imagem B, novafase ao entrar no buraco negro da Imagem A.

O projetista do jogo pode alterar a estrutura e a logica de movimentacao entreos lugares no Petri Game por meio de modificacoes no modelo em RPC, resultando emtramas diferentes. Para exemplificar, usando como modelo inicial a rede da Figura 1,removeu-se o lugar denominado planet3, resultando a rede apresentada na Figura 7.

Figure 7. Rede da Figura 1 sem o lugar planet3.

Feita a modificacao, a nova rede e processada pelo Petri Game, gerando a interfaceapresentada na imagem A da Figura 8. Com multiplos jogadores, os sprites representantesdos diversos usuarios sao renderizados em cada interface cliente. A Imagem B da Figura8 apresenta um jogo onde tres jogadores estao conectados na mesma fase.

No Petri Game, a forma de interacao com o usuario pode ser realizada de difer-entes maneiras. Atualmente, tres mecanismos estao implementados. Em equipamentosdo tipo desktop, a interacao e realizada via teclado. Em dispositivos moveis com sistemaAndroid, a interacao com o usuario pode ser realizada por meio do toque nos controlesapresentados no display (que podem ser vistos no canto inferior esquerdo das imagens

Figure 8. Imagem A, jogo gerado a partir da rede da 7. Imagem B, cenario commultiplos jogadores.

das Figuras 6 e 8) ou, ainda, pelo movimento do dispositivo, usando-se os dados geradospelo acelerometro.

6. ConclusoesEste trabalho apresentou uma ferramenta para criacao de jogos 2D distribuıdos para aplataforma Android atraves da interpretacao de um modelo em Rede de Petri Colorida.Os resultados mostraram que e possıvel criar novos jogos ou modificar as tramas de jo-gos existentes a partir de modelagem por Redes de Petri Coloridas, sem nenhum esforcoadicional de programacao, o que pode atribuir alta flexibilidade e, sobretudo, alta pro-dutividade no desenvolvimento desse tipo de aplicacao. A distribuicao do jogo tambemfoi alcancada, permitindo que multiplos usuarios joguem juntos quando e onde quiserem,sendo necessario smartphones com sistema Android e com o Petri Game instalado e umarede local. Atualmente, esta em desenvolvimento uma nova versao do Petri Game ca-paz de interpretar todos os aspectos das Redes de Petri Coloridas, tais como funcoes etemporizacoes.

ReferencesAhmed, R. and Aule, J. (2011). An evaluation of the framework libgdx when developing

a game prototype for android devices.

Araujo, M. and Roque, L. (2009). Modeling games with petri nets. Breaking New Ground:Innovation in Games, Play, Practice and Theory. DIGRA2009. Londres, Royaume Uni.

Battaiola, A. L., Elias, N. C., Domingues, R., Assaf, R., and Ramalho, G. L. (2002).Desenvolvimento da interface de um software educacional com base em interfaces dejogos. IHC Simposio sobre Fatores Humanos em Sistemas Computacionais, 5.

Bianchini, R. (2005). Uma arquitetura bdi para comportamentos interativos de agentesem jogos computacionais.

Chen, C. (2010). User interfaces for dynamic web service infrastructures–an approachfor google android. Apress Media.

Jensen, K. (1994). Coloured petri nets. basic concepts, analysis methods and practicaluse. volume 1: Basic concepts, 1992. volume 2, analysis methods, 1994. volume 3:Practical use, 1997. Monographs in Theoretical Computer Science, Springer-Verlag.

Jensen, K. and Kristensen, L. M. (2009). Coloured Petri nets: modelling and validationof concurrent systems. Springer.

Lee, Y.-S. and Cho, S.-B. (2011). Context-aware petri net for dynamic procedural con-tent generation in role-playing game. Computational Intelligence Magazine, IEEE,6(2):16–25.

Lee, Y.-S. and Cho, S.-B. (2012). Dynamic quest plot generation using petri net planning.In Proceedings of the Workshop at SIGGRAPH Asia, pages 47–52. ACM.

Santos, S. D. and Roque, L. G. (2010). Ensaio de reescrita de comportamentos em video-jogos com base no ajuste e computaA§A£o de modelos de petri net. IX SBGames.

UNIVERSIDADEFEDERALDOCEARÁ CENTRODETECNOLOGIA ...

Documents

Transcript of UNIVERSIDADEFEDERALDOCEARÁ CENTRODETECNOLOGIA ...