Faculdade Salesiana Dom Bosco
William Fontanin Rodrigues
Dengue Killer: um serious game para educação
em saúde com ênfase no combate a dengue
Piracicaba
2012
Faculdade Salesiana Dom Bosco
William Fontanin Rodrigues
Piracicaba
2012
Trabalho de Conclusão de Curso
apresentado como exigência parcial
para obtenção do grau de Bacharel em
Sistemas de Informação na Faculdade
Salesiana Dom Bosco de Piracicaba,
sob a orientação do Prof. Maurício
Carnevalli e coorientação do Prof. Me.
Kléber de Oliveira Andrade.
Dengue Killer: um serious game para educação
em saúde com ênfase no combate a dengue
Piracicaba
2012
Trabalho de Conclusão de Curso
apresentado como exigência parcial
para obtenção do grau de Bacharel em
Sistemas de Informação na Faculdade
Salesiana Dom Bosco de Piracicaba,
sob a orientação do Prof. Maurício
Carnevalli e coorientação Prof. Me.
Kléber de Oliveira Andrade.
Dengue Killer: um serious game para educação
em saúde com ênfase no combate a dengue
William Fontanin Rodrigues
Trabalho de Conclusão de Curso defendido e aprovado em 10/12/2012 pela comissão
julgadora:
__________________________________________
Prof. Dr. José Martins Junior / Faculdade Salesiana Dom Bosco
__________________________________________
Prof. Me. Kléber de Oliveira Andrade / Faculdade Salesiana Dom Bosco
__________________________________________
Prof. Dr. Renato Kraide Soffner / Faculdade Salesiana Dom Bosco
Agradecimentos
Primeiramente a Deus, pelas incríveis oportunidades.
A minha família e namorada pelo companheirismo, compreensão e apoio as
minhas decisões, que me deram forças.
Ao professor orientador Maurício Carnevalli que me ajudou nessa jornada.
Ao professor e coorientador Me. Kléber de Oliveira Andrade, por toda ajuda
durante este trabalho, me sugerindo a ideia, ajudando na compreensão do
desenvolvimento de jogos, no uso Framework XNA e nas muitas referencias
indicadas.
A todos os professores pela dedicação, ensino e atenção que nos deram
durante toda a graduação.
Ao Mergulhão que me ajudou criando imagens para o jogo.
A todos os meus amigos e companheiros de turma, sempre ajudando uns aos
outros, a Diego Doná pela produção da música do jogo.
A todos que direta ou indiretamente me ajudaram e contribuindo com este
trabalho. Depois desses longos meses de intenso trabalho espero que este trabalho
esteja à altura de todos aqueles que contribuíram para a sua conclusão.
“Tentar não. Faça, ou não faça. Tentativa não há.”
Yoda, do filme Star Wars Episodio V: O império Contra-Ataca.
Resumo
A dengue é uma doença que atinge várias pessoas no mundo e traz risco de morte,
sendo necessárias ferramentas para conscientizar as pessoas sobre o método para
combatê-la. Um dos métodos eficazes hoje em dia para educação das pessoas é o
uso de jogos eletrônicos. Esses jogos são denominados serious games, os quais
são utilizados em diversos setores, como: militar, educação, marketing, saúde, etc.
Assim, este trabalho tem como objetivo o desenvolvimento de um serious game
educativo, para transmitir informações sobre o combate a dengue através da
eliminação dos criadouros do mosquito vetor. O resultado deste trabalho é um jogo
para computador que visa a educação sobre o combate a dengue. Para o
desenvolvimento do mesmo foi criado o projeto do jogo, que contém todas as
informações necessárias para seu desenvolvimento e foi utilizado o Framework XNA
da Microsoft com a linguagem C# para a programação, pois trazem facilidades para
se desenvolver jogos. Sendo a dengue uma doença problemática que traz risco de
morte e que seu combate necessita da participação de todos, o jogo resultado deste
trabalho vem ser uma ferramenta para a conscientização das pessoas. Este trabalho
foi apresentado no 12° Congresso Nacional de Iniciação Científica CONIC e na XII
Mostra de Produção Científica UNISAL na modalidade painel, ver os ANEXOS A ao
D.
Palavras-chave: Serious games. Jogos eletrônicos. Educação em saúde. Combate a
dengue.
Sumário 1 INTRODUÇÃO .................................................................................................................................. 8
1.1 Objetivo geral .......................................................................................................................... 8
2 DENGUE ........................................................................................................................................... 9
2.1 Dengue no mundo ................................................................................................................... 9
2.2 Transmissão ........................................................................................................................... 10
2.3 Sintomas ................................................................................................................................ 11
2.4 Tratamento ............................................................................................................................ 11
2.5 Modos de combate ............................................................................................................... 12
3 JOGOS ELETRÔNICOS .................................................................................................................... 15
3.1 Serious Games ....................................................................................................................... 16
3.2 Aplicações .............................................................................................................................. 17
3.2.1 Militar ............................................................................................................................ 17
3.2.2 Governo ......................................................................................................................... 18
3.2.3 Educação ....................................................................................................................... 19
3.2.4 Corporativo.................................................................................................................... 19
3.2.5 Saúde ............................................................................................................................. 19
4 MODELAGEM ................................................................................................................................ 21
4.1 Metodologia de desenvolvimento ........................................................................................ 21
4.1.1 Scrum ............................................................................................................................. 21
4.2 XNA Framework e linguagem ................................................................................................ 24
4.2.1 Camadas do XNA ........................................................................................................... 25
4.3 UML ....................................................................................................................................... 26
4.4 Diagramas .............................................................................................................................. 27
4.4.1 Diagrama de atividade .................................................................................................. 27
4.4.2 Diagrama de caso de uso .............................................................................................. 28
5 PROJETO DO JOGO ........................................................................................................................ 32
5.1 Ideia e rascunho do jogo ....................................................................................................... 32
5.1.1 Descrição do jogo .......................................................................................................... 32
5.1.2 Objetivos do jogador ..................................................................................................... 32
5.1.3 Jogador .......................................................................................................................... 33
5.1.4 Inimigos ......................................................................................................................... 33
5.1.5 Pontuação ..................................................................................................................... 34
5.1.6 Controles ....................................................................................................................... 35
5.1.7 Estória ............................................................................................................................ 35
5.2 Fluxo do jogo ......................................................................................................................... 35
5.3 Fase ....................................................................................................................................... 36
5.4 Heads-up displays (HUD) ....................................................................................................... 39
5.5 Especificações técnicas ......................................................................................................... 40
5.5.1 Recursos utilizados ........................................................................................................ 40
5.5.2 Requisitos de hardware e sistema para o desenvolvimento ........................................ 40
6 DESENVOLVIMENTO ...................................................................................................................... 41
6.1 Primeiro Sprint ...................................................................................................................... 42
6.2 Segundo Sprint ...................................................................................................................... 44
6.3 Terceiro Sprint ....................................................................................................................... 46
6.4 Quarto Sprint ......................................................................................................................... 48
6.5 Quinto Sprint ......................................................................................................................... 49
7 CONSIDERAÇÕES FINAIS ................................................................................................................ 53
7.1 Trabalhos futuros .................................................................................................................. 53
REFERÊNCIAS ......................................................................................................................................... 55
ANEXO A – Certificado de participação no 12º Congresso Nacional de Iniciação Científica CONIC-
SEMESP .................................................................................................................................................. 58
ANEXO B – Painel apresentado no 12º Congresso Nacional de Iniciação Científica CONIC-SEMESP ... 59
ANEXO C – Certificado de participação na XII Mostra de Produção Científica UNISAL ........................ 60
ANEXO D – Painel apresentado na XII Mostra de Produção Científica UNISAL .................................... 61
8
1 INTRODUÇÃO
A Dengue é um problema de saúde mundial. É uma doença com risco de
morte e não existe tratamento específico. Todo ano milhões de pessoas são
infectadas e casos de mortes são registrados. O método eficaz para combatê-la é
através da eliminação do mosquito vetor, ao eliminar os locais onde seus ovos são
depositados. Esses locais são chamados de criadouros.
Posto isso é necessário educar a população para colaboração e participação
ao combate a dengue. Uma tentativa pedagógica utilizada atualmente para fins
semelhantes são os jogos eletrônicos, denominados serious games, que são uma
ferramenta diferenciada e de uso crescente em diversos setores, tais como militar,
saúde, educação, etc. Como aspectos positivos de seu uso, pode-se nomear a
retenção de informações com maior facilidade, ao mesmo tempo em que prende a
atenção do jogador para conhecimento da doença. Outro aspecto relevante com
relação aos jogos é a participação direta na vida das pessoas, estimulando-as a
busca de novos conhecimentos.
1.1 Objetivo geral
Este trabalho tem como objetivo transmitir informações através de um jogo a
ser desenvolvido para educação sobre o combate a dengue. No jogo os principais
criadouros serão os inimigos que ganharam vida, a fim de, atrapalhar o objetivo
principal do jogador que é eliminá-los e deixá-los na posição em que estes não
ofereçam mais o perigo de um criadouro ativo. Para que este trabalho fosse
desenvolvimento, realizaram-se pesquisas sobre a dengue e serious games,
voltados à educação. O jogo foi desenvolvido com o uso do XNA Game Studio da
Microsoft e a linguagem C#.
9
2 DENGUE
De acordo com a World Health Organization (WHO, 2012a) a dengue se trata
de uma infecciosa causada por vírus que são transmitidos principalmente pelo
mosquito Aedes aegypiti encontrado em áreas tropicais e subtropicais e pelo
mosquito Aedes albopictus em alguns países. Ainda segundo WHO (2012a) existem
quatro tipos de vírus da dengue conhecidos como de DEN-1, DEN-2, DEN-3 e DEN-
4. A infecção por um vírus torna a pessoa imune ao vírus que foi infectada, mas não
ao outros vírus.
O Portal da Saúde do Ministério da Saúde (MS, 2012) apresenta dois tipos de
dengue, a clássica e a hemorrágica, chamada de dengue severa pela WHO (2012a),
as formas se diferem pelos sintomas, a forma hemorrágica é a mais severa e pode
ter como consequência a morte.
2.1 Dengue no mundo
Segundo a WHO (2012b) a dengue hemorrágica foi identificada no ano de
1950 nas Filipinas e Tailândia onde se teve epidemia naquele ano. Antes de 1970
eram nove países que tinham passado por epidemias graves de dengue e
atualmente são mais de 100 países em que a dengue é endêmica, ou seja, acontece
com frequência.
A dengue é um problema de saúde pública mundial, WHO (2012a) relata que
mais de 2,5 bilhões de pessoas correm risco de contrair dengue e também calcula
que 50 a 100 milhões de pessoas possam ser infectadas por ano no mundo.
Somente nas Américas em 2010 foram relatados 1,6 milhão de casos da doença e
desses 49 mil casos graves contra 1,2 milhão de casos nas Américas, Sudeste
Asiático e Pacífico Ocidental, mostrando aumento nos casos de dengue. A Figura 1
indica os países e áreas onde se tem risco da doença.
10
Figura 1 – Dengue, países ou áreas de risco
Fonte: Organização Mundial de Saúde (2012c).
2.2 Transmissão
A transmissão da dengue acontece através da picada do mosquito fêmea
infectado. O mosquito é infectado quando pica alguém que está com a doença e ele
irá transmitir a doença por toda sua vida. A Figura 2 apresenta o ciclo de vida do
mosquito.
Figura 2 – Ciclo de vida do mosquito da dengue
Fonte: Guia Básico de Dengue (YASUMARO et al, 2002).
11
2.3 Sintomas
Segundo MS (2012) existem alguns sintomas nos quais é possível
determinar se a pessoa está com dengue clássica ou hemorrágica.
Dengue clássica:
Febre alta, dor no corpo, dores nos ossos e articulações, dor de cabeça, dor
atrás do olho, perda do paladar e apetite, náuseas e vômitos, tonturas, cansaço,
moleza, manchas e erupções na pele.
Dengue hemorrágica:
Apresenta os mesmos sintomas da dengue clássica e também após terminar
a febre surgem dores abdominais fortes e contínuas, vômitos persistentes, pele
pálida, fria e úmida, sangramento pelo nariz, boca e gengivas, manchas vermelhas
na pele, sonolência, agitação e confusão mental, sede excessiva e boca seca, pulso
rápido e fraco, dificuldade respiratória e perda da consciência.
2.4 Tratamento
Não existe um tratamento específico para a doença, o paciente deve procurar
ajuda médica, repousar e beber bastante líquido. Para alívio das dores e febre é
usado o Paracetamol, mas não devem ser tomados a Aspirina e o Ibuprofeno, pois
estes medicamentos aumentam o risco de hemorragia. Nos casos graves são
necessários cuidados médicos, sendo a principal medida o controle do volume
líquido circulante no paciente para conter o agravo da doença e salvar vidas (WHO,
2012a).
12
2.5 Modos de combate
O único método de combate a dengue segundo a WHO (2012a) é o combate
ao mosquito vetor, eliminando seus criadouros. Os criadouros podem ser vistos na
Figura 3.
Figura 3 – Criadouros e medidas de combate
Fonte: Ministério da Saúde (CARTILHA DA DENGUE, 2007).
WHO (2012b) ainda relata três métodos para o combate ao vetor, a gestão
ambiental, controle químico e o controle biológico e nas Diretrizes Nacionais para a
Prevenção e Controle de Epidemias de Dengue (DNPCED, 2009) além desses, tem
o controle mecânico, o controle legal e traz também como medida de prevenção a
comunicação e mobilização.
Gestão ambiental
A gestão ambiental tem objetivo de modificar o ambiente com a destruição,
alteração, eliminação ou reciclagem de recipientes que servem como local para os
ovos, larvas e pupas. Dessa forma ela visa também melhorias no abastecimento de
água e fornecimento confiável para que não seja necessário armazenamento de
água. No caso de necessidade de recipientes para armazenamento, os recipientes
13
devem ser a prova de mosquito, com tampas vedadas. Os resíduos sólidos devem
ter a coleta, destinação e eliminação adequada, sendo recolhidos em sacos
plásticos e coletados duas vezes por semana. Deve-se ter um sistema de limpeza
de ruas regular para recolhimento de descartados que possam acumular agua. Nas
construções e reformas surge a oportunidade de se modificar e reduzir os locais com
potencial para serem criadouros (WHO, 2012b).
Controle químico
O controle químico é considerado pela WHO como complemento a gestão
ambiental, a não ser em casos de emergência, quando o controle químico é feito nos
recipientes que não podem ser monitorados ou eliminados. Neste controle são
usadas substâncias químicas para controle do vetor tanto na faze larvária como na
fase adulta (WHO, 2012b).
Controle biológico
O controle biológico utiliza de organismos que atacam, parasitam ou
competem com o Aedes. São usados peixes e crustáceos de água doce contra as
formas imaturas de larva do mosquito (WHO, 2012b).
O controle biológico adotado pelo Ministério da Saúde que é informado nas
DNPCED (2009) é o uso do Bacillus thuringiensis israelenses (Bti). O Bti atua
produzindo endotoxinas proteicas que são ingeridas pela larva do mosquito
causando sua morte.
Controle legal
O controle legal prevê medidas de caráter legal que visam principalmente
responsabilizar os proprietários pela manutenção e limpeza de terrenos baldios,
garantir a visita domiciliar do Agente de Controle de Endemias (ACE) aos imóveis
fechados, abandonados e onde não é permitida a inspeção (DNPCED, 2009).
Controle mecânico
O controle mecânico é composto de praticas para impedir a procriação do
Aedes, tendo como principais atividades a destruição ou destinação adequada de
criadouros que são feitas pelo morador/proprietário com a supervisão do Agente de
Controle de Endemias (ACE) ou Agente Comunitário de Saúde (ACS). Também é
feito o controle mecânico em larga escala como coleta de resíduos sólidos e
destinação final adequada do mesmo e o armazenamento e destino adequado dos
pneus (DNPCED, 2009).
14
Comunicação e mobilização
Tem como objetivo realizar práticas educativas com ações de comunicação
para poder mobilizar as pessoas e sociedade organizada, criando consciência do
problema da dengue e assim fazer com que as pessoas participarem das ações de
combate. Faz parte das ações a divulgação das medidas de prevenção para
incentivar a adoção delas e evitar a proliferação do mosquito vetor. DNPCED (2009)
cita como primordial a comunicação como ferramenta para a divulgação de
informações da dengue e para informar a sociedade de seu papel nas ações de
combate a dengue.
15
3 JOGOS ELETRÔNICOS
Os jogos e brincadeiras fazem parte da humanidade desde os primórdios e
constitui em um dos aspectos que definem a própria existência da humanidade, pois
eles são importantes elementos da cultura e um traço essencial da sociedade
humana. Os homens jogam e brincam de forma consciente durante toda a vida para
obter prazer (CRUZ; ALBUQUERQUE; AZEVEDO, 2009).
Jogos têm várias definições ligeiramente diferentes, Michael e Chen (2006)
citam uma síntese para a definição de jogos, que eles são atividades voluntárias,
fora da vida real, onde se tem um mundo imaginário que prende toda a atenção do
jogador, eles acontecem em um tempo e lugar específico e são regidos por regras.
Existem varias funções para os jogos na sociedade, sendo a principal oferecer
lazer e diversão. Eles oferecem um ambiente para a investigação e busca de
soluções livre de pressões e avaliações que favorecem o aprendizado pelo erro,
tendo assim como beneficio o estimulo da exploração em que se pode errar, sendo
assim os jogos completam o conhecimento do individuo (KISHIMOTO, 1994 APUD
CRUZ; ILHA, 2007).
Existem vários fatores para que os jogos sejam utilizados além do mero
entretenimento.
Os jogos segundo Clark Abt (1987 apud MICHAEL; CHEN, 2006) são
motivadores e tratam de vários conceitos e fatos e assim, são dispositivos eficazes
para treinamento e ensino.
Eles fornecem uma visão do tema ou problema em estudo possibilitando o
jogador enfrenta-lo, definir estratégias, tomar decisões e ter retorno rápido das
consequências de suas escolhas sem que elas sejam reais (MICHAEL; CHEN,
2006). Os jogos eletrônicos podem contribuir para o desenvolvimento cognitivo, pois
fazem com que o jogador tome decisões e as priorizem com base em um trabalho
intelectual.
Este trabalho intelectual é composto pelo aprendizado das regras, pois
raramente elas são totalmente definidas antes que se jogue. Também faz com que o
jogador trabalhe com vários objetivos ao mesmo tempo, tendo que gerenciá-los para
progredir. Ele ainda tem que explorar o mundo virtual para ter uma hipótese do que
os eventos podem significar e escolher um para ver se tem o resultado esperado.
16
Esse processo faz com que o jogador aprenda por tentativa e erro com base nos
desafios vencidos.
Portanto os jogos eletrônicos fazem com que os jogadores aprendam a
aprender, a pensar e refletir sobre os acontecimentos e narrativa do jogo
(JOHNSON, 2005 APUD CRUZ; ALBUQUERQUE; AZEVEDO, 2009).
Os jogos por natureza fazem com que o jogador aprenda, pois o jogador deve
no mínimo aprender as regras do jogo e a partir do entendimento delas o jogador
começa a buscar novas formas e estratégias para aplica-las (MICHAEL; CHEN,
2006).
Eles trazem ainda outros benefícios como apoio ao desenvolvimento de
habilidades como a analítica, espacial, estratégica, discernimento, capacidade de
aprendizagem e memória, psicomotoras, atenção seletiva visual, melhora na auto
monitoração, no reconhecimento de problemas e solução, na tomada de decisão, na
negociação, colaboração e alivio da frustração (SUSSI; JOHANNESSON;
BACKLUND, 2007).
3.1 Serious Games
Segundo Marsh (2011) os serious games são jogos digitais, simulações,
ambientes de realidade virtual, mista e mídia que fornecem um meio para
desenvolver uma atividade através de uma narrativa, jogabilidade ou encontro para
informar, influenciar, para o bem estar e / ou experiência para a transmissão de um
proposito.
Michael e Chen (2006) definem que os serious games são jogos que tem
como principal objetivo a educação, eles podem ser usados para todos os tipos de
educação e em todas as idades. Outra definição apresentada é que os serious
games são jogos que são utilizados para passar uma mensagem, ensinar uma lição
ou oferecer uma experiência ao jogador.
17
3.2 Aplicações
Os serious games devido as suas vantagens são usados nos mais variados
setores. Eles são usados principalmente em setores como o militar, governo,
educação, corporativo e da saúde (MICHAEL; CHEN, 2006). Nos próximos
subtópicos serão apresentados estes setores.
3.2.1 Militar
Os serious games permitem ao setor militar criar simulações para serem
usadas em treinamentos, para preparação de missões, ensino de línguas e
formação cultural estrangeira. Algumas vantagens desses jogos no setor militar são
para melhoria na coordenação olho mão, aumento da capacidade multitarefa e
habilidade de trabalho em equipe com o mínimo de comunicação. O primeiro jogo
usado para o treinamento militar foi o chamado Army Battlezone criado pela Atari
(SUSSI; JOHANNESSON; BACKLUND, 2007).
Figura 4 - Battlezone
Fonte: Atari (2012).
18
O jogo America’s Army (Figura 5) é um dos mais conhecidos jogos utilizados
na área militar, ele foi utilizado primeiramente pelo Exército Americano para
aumentar o ingresso de recrutas no Exército. Além disso, ele é utilizado para o pré-
treinamento dos soldados e para preparo pra missões (SUSSI, JOHANNESSON,
BACKLUND, 2007).
Figura 5 – America’s Army
Fonte: Superdownloads (2009).
3.2.2 Governo
O governo tem a vantagem de poder criar cenários de diversos locais com
níveis de gravidades e situações perigosas, que podem ser repetidos, que seriam
impossíveis ou caros para se construir realmente com um baixo custo. Os jogos são
utilizados pelos governos para simulação e formação que incluem diversas tarefas e
situações como, por exemplo, ataques terroristas, surto de doenças, questões
relacionadas à saúde, atendimento ao publico, planejamento urbano, controle de
tráfego, combate a incêndios, ética entre outras aplicações (MICHAEL; CHEN,
2006).
19
3.2.3 Educação
Os jogos para educação são considerados uma ferramenta de ensino e
formação. Essa ferramenta tem como valor ser eficaz no ensino (MICHAEL; CHEN,
2006). Assim eles têm como diferenciais ser um facilitador da aprendizagem de
temas complexos, desenvolver habilidades cognitivas, como o raciocino rápido,
criatividade, percepção e resolução de problemas, proporcionado à imersão de
quem joga (PRENSKY, 2001; GEE, 2003 APUD GHENSEV, 2012).
Outro fator para o seu uso é o fato deles poderem aumentar o engajamento
do jogador através da imersão, possibilitando que o jogador assuma riscos
intelectuais sem medo de fracassar, criando interação entre os jogadores e podendo
se adaptar a vários modos de aprendizado. Eles são utilizados para gerar
conhecimento e para reforçar os conhecimentos já adquiridos (GHENSEV, 2010).
3.2.4 Corporativo
Devido ao desinteresse pelos treinamentos corporativos tradicionais as
organizações têm adotado os jogos para seus treinamentos com o objetivo de
construir as habilidades dos funcionários, isso se deve ao fator de que a média de
um comprador de jogo ser de 36 anos oque aumenta a possibilidade deles fazerem
parte das organizações. Com o uso de jogos os funcionários estão imersos no que
se pretende ensinar e não mais sendo expostos a informações que podem ser
ignoradas como nos outros métodos (MICHAEL; CHEN, 2006).
3.2.5 Saúde
Na saúde os jogos vêm sendo utilizados para ajudar no treinamento de
médicos, no preparo de médicos para cirurgias delicadas, na recuperação dos
pacientes, para promover o bem estar, ajuda para os pacientes com problemas
20
mentais, para distrair os pacientes em procedimentos que são dolorosos, para
melhorar a habilidade motora e em fisioterapias para acelerar a recuperação.
Para os idosos os jogos os ajudam a permanecerem saudáveis e
mentalmente alerta melhorando o tempo de reação, o bem estar, a função cognitiva,
memoria e estado emocional.
Os jogos no treinamento médico têm como vantagem possibilitar aos médicos
praticarem cirurgias ou procedimento perigosos sem ter que fazer na pessoa. Outra
vantagem é que os jogos se mostram eficaz em focar a atenção do paciente fazendo
com que ele sinta menos dor por não estar tão consciente do que está acontecendo,
também podem trazer distração para pacientes antes de cirurgias e procedimento
médicos fazendo com que se diminua a ansiedade.
Outro uso para os jogos é aumentar a autogestão de doenças crônicas que
dependem dos pacientes ajustarem seu modo de vida e hábitos. Os jogos podem
ensinar os jogadores a se manterem saudáveis, abordando temas como nutrição,
condicionamento físico, doenças sexualmente transmissíveis, promovendo
mudanças e no tratamento de fobias (MICHAEL; CHEN, 2006).
21
4 MODELAGEM
Neste capitulo é abordado a modelagem do jogo, apresentando a metodologia
de desenvolvimento, o Framework XNA e os diagramas utilizados.
4.1 Metodologia de desenvolvimento
A metodologia consiste em atividades, ações e tarefas que são necessárias
para desenvolver um software (PRESSMAN, 2006). Nesse trabalho foi utilizada a
metodologia Scrum.
4.1.1 Scrum
Scrum é definido como um framework incremental para projetos e que
também é utilizado como metodologia para o desenvolvimento de softwares. Scrum
fornece suporte ao desenvolvimento de produtos complexos e visa o
desenvolvimento de forma iterativa e incremental para melhorar a previsão e
controle dos riscos durante o processo de desenvolvimento. As interações e
incrementos do Scrum são denominados de Sprints (SCHWABER; SUTHERLAND,
2011). O Scrum conta também com os artefatos que visam aumentar a
transparência das informações e com os participantes que definem os papéis de
cada um durante o projeto.
Os Sprints são ciclos de trabalho executados um após o outro, com prazo
mínimo de duas semanas e máximo de quatro semanas. O Sprint acaba em uma
data determinada e não se estende o prazo, mesmo se todo o trabalho não for
concluído.
No começo de um Sprint a equipe seleciona as tarefas a serem realizadas em
uma lista de prioridades. Todo dia a equipe verifica o progresso das tarefas para
poder definir as próximas etapas para termina-las. Ao final do Sprint o trabalho
22
entregue deve ser algo utilizável para que os interessados possam acompanhar o
trabalho feito (DEEMER et al, 2012).
Artefatos do Scrum
Os artefatos do Scrum tem objetivo de aumentar a transparência das
informações que são necessárias para que o time do Scrum entregue um
incremento pronto, eles são o Product Backlog e o Backlog do Sprint.
Product Backlog
É uma lista com ordem definida do que é preciso no produto, onde itens que
estão no topo da lista tem maior prioridade sendo desenvolvidos primeiro. O Product
Backlog sofre mudanças conforme o produto é desenvolvido e nele são listados as
características, funções, requisitos, melhorias e correções das modificações que
devem ser feitas no produto (SCHWABER; SUTHERLAND, 2011).
Backlog do Sprint
São os itens do Product Backlog que são separados para o Sprint, um plano
para entrega do produto e realização da meta estipulada, ele contem o trabalho que
a equipe de desenvolvimento irá fazer para transformar os itens do Product Backlog
em um incremento, tornando o trabalho da equipe de desenvolvimento acessível aos
demais. Durante o Sprint o Backlog do Sprint é modificado pela equipe de
desenvolvimento devido ao maior entendimento da equipe sobre o trabalho que é
preciso para atingir a meta (SCHWABER; SUTHERLAND, 2011).
Participantes do time do Scrum
Os participantes do time do Scrum são compostos por Product Owner,
ScrumMaster e a equipe de desenvolvimento.
Product Owner
É a pessoa responsável por definir as tarefas que compõem o produto e
também criar uma lista ordenada dessas tarefas (Product Backlog) para que se
tenha um melhor resultado. Ele é responsável por ajudar os participantes a terem
um melhor entendimento do produto em desenvolvimento e deve ter melhor
entendimento para que o produto final tenha um melhor valor para os interessados
(SCHWABER; SUTHERLAND, 2011).
Scrum Master
Ele tem a função de verificar se a equipe segue as praticas e valores do
Scrum, ajuda a equipe a fazer o trabalho da melhor forma e também a usar o Scrum.
O Scrum Master é o responsável por desfazer qualquer impedimento para o
23
progresso do projeto, facilita reuniões e ajuda o Product Owner a manter o Product
Backlog (MOUNTAIN GOAT SOFTWARE, 2012).
Equipe de Desenvolvimento
Profissionais responsáveis por entregar um utilizável ao final de cada ciclo de
trabalho (Sprint). A equipe é multifuncional, possuindo todas as capacidades para
concluir o ciclo, se organizar e gerenciar o trabalho (SCHWABER; SUTHERLAND,
2011).
Eventos
Os eventos têm a finalidade de definir uma rotina e evitar reuniões não
definidas no Scrum. Esses eventos têm uma duração máxima para poder ter o
tempo necessário de planejamento, eles são apresentados a seguir.
Reunião de planejamento do Sprint
Essa reunião tem o objetivo de planejar o trabalho que será realizado no
Sprint e é feita por todo time do Scrum. Ela define qual vai ser o resultado no final do
Sprint e como dever ser realizado o trabalho para alcançar o resultado. Essa reunião
deve ter um tempo máximo de oito horas.
A equipe de desenvolvimento planeja o trabalho que prevê para o Sprint e
divide esse trabalho em partes de um dia ou menos de duração para se auto
organizar e realizar o trabalho.
O Product Owner deve classificar os itens escolhidos para o Sprint e ajudar
nas escolhas. No fim da reunião a equipe de desenvolvimento deve ser capaz de
explicar como pretende trabalhar para chegar ao resultado (SCHWABER;
SUTHERLAND, 2011).
Reunião diária
Reunião feita pela equipe de desenvolvimento para definir um plano para as
próximas 24 horas. Essa reunião é usada pela equipe para avaliar o progresso do
Sprint e do trabalho todo, ela tem duração de 15 minutos.
Essa reunião permite melhorar a comunicação, detectar impedimentos para o
desenvolvimento e eliminá-los, ter rápidas tomadas de decisão e tornar o nível de
conhecimento da equipe de desenvolvimento melhor (SCHWABER; SUTHERLAND,
2011).
Revisão do Sprint
Ao final do Sprint é realizada a revisão para verificar o resultado obtido e
adaptar o Product Backlog. Essa reunião tem duração de quatro horas.
24
Nessa reunião, o Product Owner identifica oque foi feito e oque não foi. A
equipe de desenvolvimento relata oque ocorreu bem, os problemas ocorridos e
como foram resolvidos, mostra o resultado obtido e responde às questões. O
Product Owner estima as datas para conclusão do trabalho, o time Scrum discute o
que fazer a seguir e o Product Backlog é revisado (SCHWABER; SUTHERLAND,
2011).
Retrospectiva do Sprint
Reunião destinada ao time Scrum para se revisar e definir melhorias para o
próximo Sprint. Ela tem duração de três horas.
Essa reunião tem o objetivo de rever como foi a relação entre as pessoas,
processos e ferramentas no ultimo Sprint, identificar os itens que foram bem, as
potenciais melhorias e criar um plano para realizar essas melhorias (SCHWABER;
SUTHERLAND, 2011). A Figura 6 representa uma visão gráfica do Scrum.
Figura 6 - Visão gráfica do Scrum
Fonte: Mountain Goat Software (2005).
4.2 XNA Framework e linguagem
O XNA foi lançado pela Microsoft em 2006 e é um conjunto de bibliotecas
multi-plataforma para o desenvolvimento de jogos para Windows, Xbox 360,
Windows Phone 7, Zune e Zune HD. A versão atual é a 4.0, liberada em 16 de
setembro de 2010. O XNA tem como linguagem oficial o C# e todos os modelos e
25
exemplos do XNA são feitos com a linguagem C# (XNA FRAMEWORK OVERVIEW,
2011).
4.2.1 Camadas do XNA
O XNA é composto por quatro camadas (Figura 7), onde cada uma tem
responsabilidades específicas.
Figura 7 - Camadas do XNA
Fonte: Revista Nintendo Blast n° 6 (2010, p.56).
A Camada Jogos é onde ficam as aplicações e jogos prontos para execução
ou modificação. Os starter kits são kits prontos que servem como final ou partida
para o desenvolvimento. Nessa camada também ficam os códigos do jogo e seus
conteúdos como sons, imagens entre outros e os componentes criados pela
comunidade para ser usados nos jogos.
A camada de Extensões tem o Modelo de Aplicação que é responsável por
criar e gerenciar janelas, executar a inicialização do DirectX, gerenciar o game loop
26
de execução do jogo e criar a estrutura básica de código quando criado um projeto
para desenvolvimento. Nessa camada fica o Content Pipeline que processa todo o
conteúdo que será utilizado durante o jogo. Ele importa os conteúdos e os
transforma em arquivos binários que serão usados facilitando o trabalho do
programador de tratar os vários tipos de conteúdo.
Na camada de Núcleo encontra-se o Graphics tem que a capacidade de
renderização usando DirectX, ele conta com vários recursos como o BasicsEffecs
para objetos 3D e o SpriteBach para gráficos 2D. Outro item dessa camada é o
Áudio que tem os recursos para tratar os áudios, o Input é responsável pela entrada
de dados do usuário podendo ser pelo teclado, mouses, Gamepad entre outros. A
Math responsável pelos cálculos no jogo e funções para lidar com movimentos,
colisões, vetores, etc. O Storage permite salvar e ler dados dos jogos e a Network
facilita a comunicação via rede ou online.
A Camada de Plataforma é a base para todas as outras camadas acimas
sendo que todas elas utilizam alguma componente desta camada (REVISTA
NINTENDO BLAST, n°6, 2012).
4.3 UML
A UML é um conjunto de notações gráficas que ajuda na descrição e no
projeto de softwares. A UML é a união de muitas linguagens gráficas de modelagem
orientada a objetos que surgiram no final dos anos oitenta (FOWLER, 2005).
Existem 13 tipos de diagramas na UML que são divididos em diagramas de
estrutura, comportamento e interação.
Os diagramas de estrutura são: diagrama de classe, de objetos, de
componentes, estrutura de composição, diagrama de pacote e de implantação. Os
diagramas de comportamento são: diagrama de caso de uso, de atividades e
máquina de estados. E os diagramas de interação são: diagrama de sequência, de
comunicação, de tempo e de visão geral da integração (OBJECT MANAGEMENT
GROUP, 2012).
Neste trabalho são usados os digramas de atividades e casos de usos,
abordados na sessão seguinte.
27
4.4 Diagramas
Nos próximos subtópicos são apresentados os diagramas utilizados no
desenvolvimento do jogo.
4.4.1 Diagrama de atividade
Na Figura 8 temos o diagrama de atividade que representa o fluxo do jogo.
Figura 8 – Fluxo do Jogo
Fonte: Próprio autor (2012).
O jogo inicia com uma tela de abertura com o nome do jogo e após cinco
segundos é mostrado o menu. No menu o jogador pode escolher entre jogar ou sair.
Quando escolhido sair o jogo é terminado, quando escolhido jogar são apresentadas
as cenas com a estória do jogo e ao termino delas é iniciado a fase do jogo. Durante
o jogo se pressionado a tecla Esc ou P o jogo é pausado e apresentado a tela de
menu de pause do jogo com as opções de continuar ou sair, caso escolhido sair o
28
jogo volta a menu inicial e se escolhido continuar volta-se a fase. Ao terminar a fase
é mostrada a pontuação e a imagem de fim na tela de final de jogo e ao pressionar
Esc volta ao menu inicial do jogo.
4.4.2 Diagrama de caso de uso
Menu:
O menu é uma tela do jogo em que o jogador poder escolher entre jogar e
sair, a Figura 9 trata-se do caso de uso do menu.
Figura 9 – Casos de usos Menu
Fonte: Próprio autor (2012).
Nas tabelas 1 e 2 são apresentadas as descrições dos casos de usos do
menu.
29
Tabela 1 – Caso de uso Iniciar Jogo
Caso de Uso Iniciar Jogo
Descrição O jogador inicia o jogo
Ator Principal Jogador
Fluxo Jogador seleciona o item de menu
jogar.
O jogo apresenta a cena de entrada da
fase e após Inicia a fase.
Pós-condição Fase iniciada.
Fonte: Próprio autor (2012).
Tabela 2 – Caso de uso Sair
Caso de Uso Sair
Descrição Encerrar o aplicativo do jogo
Ator Principal Jogador
Fluxo Jogador seleciona o item de menu Sair.
O jogo termina a sua execução.
Pós-condição Jogo encerrado.
Fonte: Próprio autor (2012).
Gameplay:
O gameplay trata-se da jogabilidade, as opções e ações que o jogador pode
fazer durante o jogo. Figura 10 apresenta o caso de uso do gameplay.
30
Figura 10 – Caso de uso Gameplay
Fonte: Próprio autor (2012).
As tabelas 3 a 6 apresentam as descrições dos casos de usos Gameplay.
Tabela 3 – Caso de uso Andar
Caso de Uso Andar
Descrição Jogador faz personagem andar
Ator Principal Jogador
Fluxo Jogador aciona uma das teclas que faz
o personagem andar.
Personagem anda na direção
correspondente a tecla pressionada.
Pós-condição Personagem ter andado.
Fonte: Próprio autor (2012).
31
Tabela 4 – Caso de uso Pular
Caso de Uso Pular
Descrição Jogador faz o personagem pular
Ator Principal Jogador
Fluxo Jogador aciona a tecla de pulo.
Personagem realiza o movimento do
pulo.
Pós-condição Personagem no solo do jogo.
Fonte: Próprio autor (2012).
Tabela 5 – Caso de uso Pausar o Jogo
Caso de Uso Pausar o Jogo
Descrição Jogador pausa o jogo
Ator Principal Jogador
Fluxo Jogador aciona a tecla de pause.
Jogo mostra a tela de pause com as
opções de continuar ou sair.
Pós-condição Jogo pausado.
Fonte: Próprio autor (2012).
Tabela 6 – Caso de uso Sair
Caso de Uso Sair
Descrição Jogador sai do jogo
Ator Principal Jogador
Fluxo Jogador seleciona a opção de sair e o
jogo volta ao menu inicial
Pós-condição Jogo no menu inicial
Fonte: Próprio autor (2012).
32
5 PROJETO DO JOGO
Neste capitulo é descrito o projeto do jogo.
5.1 Ideia e rascunho do jogo
A seguir é apresentada a ideia do jogo contendo a descrição do jogo,
objetivos do jogador, jogador, inimigos, pontuação, controles e a estória do jogo.
5.1.1 Descrição do jogo
O jogo é no estilo plataforma onde o jogador enfrentará os inimigos que são
os principais criadouros do mosquito da dengue.
5.1.2 Objetivos do jogador
O jogador tem como objetivo eliminar os inimigos que contabilizam pontos e
chegar ao final da fase onde tem um símbolo da dengue, que encerra a fase e salva
o planeta do perigo de ser tomado pela dengue. Ao terminar a fase é apresentada a
pontuação do jogador e caso ele tenha eliminados todos os inimigos ele ganha um
bônus na pontuação, assim incentivando o combate a todos os criadouros.
33
5.1.3 Jogador
O jogador é representado por um personagem que é um garoto chamado
“Zac”. Ele pode andar pela fase, pular os obstáculos e para matar os inimigos ele
deve pular sobre eles. Ele começa com três vidas exibidas no topo da tela, quando o
jogador é atingido por um inimigo ele morre, perde uma vida e volta ao inicio da fase.
Na Figura 11 temos o jogador.
Figura 11 – Jogador
Fonte: Próprio autor (2012).
5.1.4 Inimigos
Os inimigos são baseados em objetos que os mosquitos usam como
criadouro, todos os inimigos se movimentam em uma área definida e se tocam o
jogador o mesmo morre, os inimigos morrem se o jogador pular sobre eles. Os
inimigos são:
Vasos de plantas com prato, que acumulam água nos pratos que ficam em
baixo dos vasos;
Garrafas, que acumulam água no seu interior;
Pneus, que acumulam água no seu interior;
Lixeiras, que acumulam agua no seu interior;
Nas Figuras 12, 13, 14 e 15 temos os inimigos.
34
Figura 12 – Vaso de planta
Fonte: Próprio autor (2012).
Figura 13 – Garrafa
Fonte: Próprio autor (2012).
Figura 14 – Pneu
Fonte: Próprio autor (2012).
Figura 15 – Lixeira
Fonte: Próprio autor (2012).
5.1.5 Pontuação
A pontuação é obtida ao matar os inimigos, sendo que, a cada inimigo morto o
jogador ganha 100 pontos. Caso o jogador termine o jogo matando todos os
inimigos, ele ganha um bônus de 2000 pontos, que se trata de uma forma de
mostrar a importância de combater todos os inimigos.
35
5.1.6 Controles
A movimentação do personagem será através do teclado, as teclas de
movimento são:
– movimenta para a esquerda;
– movimenta para direita;
ou espaço– pula;
Esc ou P – pausa o jogo.
5.1.7 Estória
Em um dia normal aconteceu algo inusitado, quando uma erupção solar
atingiu a terra e por algum motivo que ninguém sabe, os mosquitos da dengue foram
modificados. Mas no começo ninguém percebeu, até que começou acontecer coisas
entranhas nas cidades. Quando uma pessoa tenta eliminar um criadouro da dengue,
esse ganha vida e começa ataca-las. Assim a dengue está se espalhando cada vez
mais e o planeta todo está em risco.
Um garoto chamado Zac que, ao mesmo tempo em que os mosquitos da
dengue se modificaram com a erupção solar, ele também sofreu modificações. Ao
saber que os criadouros começaram a ganhar vida, soube de uma forma que nem
mesmo ele sabe que ele é o único que pode combater esses criadouros. Agora Zac
vai enfrentar todos os criadouros da dengue e salvar o planeta.
5.2 Fluxo do jogo
O jogo inicia com uma tela de abertura onde é apresentado o nome do jogo.
Em seguida o jogador visualiza a tela de menu do jogo onde tem as seguintes
opções: jogar e sair. Na Figura 16 é apresentada a tela de abertura do jogo.
36
Figura 16 – Tela de abertura
Fonte: Próprio autor (2012).
Na primeira opção o jogo é iniciado apresentando a estória inicial e ao termino
inicia-se a fase. Na segunda opção encerra-se o jogo. A qualquer momento da fase
o jogador pode aperta ESC ou P e pausar o jogo.
Quando termina a fase é mostrada para o jogador à sua pontuação no jogo.
Após, é mostrada uma cena de fim de jogo, dizendo ao jogador que deve combater
os locais que podem ser criadouros da dengue e também falar para as demais
pessoas.
5.3 Fase
O jogo tem uma fase com vários inimigos sendo eles dos quatros tipos de
inimigos. A fase inicia com cenas de entrada (cutscenes) que contam a história do
jogo e mostra os sintomas da dengue. As Figuras 17, 18, 19 e 20 são as cenas de
entradas que são mostradas nessa ordem no jogo.
37
Figura 17 – Primeira cena
Fonte: Próprio autor (2012).
Figura 18 – Segunda cena
Fonte: Próprio autor (2012).
38
Figura 19 – Terceira cena
Fonte: Próprio autor (2012).
Figura 20 – Quarta cena
Fonte: Próprio autor (2012).
39
5.4 Heads-up displays (HUD)
Hud’s são elementos que permanecem na tela durante a execução do jogo
para indicar status ao jogador. Podem ser usados para mostrar, por exemplo, a vida
do jogador. Em resumo é um método para mostrar informações para o jogador
durante o jogo (WILSON, 2006). O Hud usando nas fases é semelhante ao da
Figura 21 apresentado a seguir.
Figura 21 – Hud
Fonte: Próprio autor (2012).
1. Indicador da fase: o indicador fica localizado no campo superior esquerdo,
traz a informação da fase em que o jogador está. É mostrado um texto com o nome
da fase;
2. Indicador de vidas: ele fica localizado ao centro e no topo, marca a
quantidade de vidas que o jogador tem. É representado por texto com o número de
vidas;
3. Indicador de pontos: fica no canto superior direito e registra os pontos que o
jogador tem na fase, indicado em forma de número.
40
5.5 Especificações técnicas
A seguir são apresentados os recursos e requisitos utilizados para o
desenvolvimento do jogo.
5.5.1 Recursos utilizados
Para o desenvolvimento foram utilizados os seguintes recursos:
Microsoft Visual Studio 2010 – ambiente integrado de desenvolvimento
Framework XNA 4.0 – framework para desenvolvimento de jogos
tIde Tile Map Editor – editor de mapa de tile, usando para criar cenários para
jogos.
Astah – editor de diagramas UML.
5.5.2 Requisitos de hardware e sistema para o desenvolvimento
Para o desenvolvimento de jogos utilizando o XNA são necessários os
seguintes requisitos:
Windows XP ou superior;
Microsoft Visual Studio 2010;
Microsoft .NET Framework 4.0;
DirectX 9.0c ou superior;
Placa de vídeo suporte a Shader Model 1.1, recomendado Shader
Model 2.0.
41
6 DESENVOLVIMENTO
O desenvolvimento foi realizado usando o XNA Game Studio da Microsoft,
que contém o XNA Framework, que utiliza a linguagem de programação C# por ser
a linguagem oficial do Framework. Também foram utilizadas duas engines, que são
pacotes de funcionalidades ou bibliotecas para facilitar o desenvolvimento, a xTile
para carregar e manipular o cenário e a Farseer Physics Engine para a detecção de
colisão e física do jogo.
Durante o desenvolvimento houve problemas de desempenho (lentidão) no
jogo quando o cenário era movimentado em acordo do andar do personagem. Esse
problema surgiu quando foi implementada a física no caminho que o personagem se
movimenta, este problema ocorreu devido o número de objetos que realizam a
física, que estavam sendo criados usando a resolução 800 x 600 pixels, o problema
de lentidão foi resolvido alterando a resolução do jogo para 640 x 480 pixels.
A versão atual do jogo conta com um menu principal com opções de jogar e
sair, também conta com cenas exibidas antes do início do jogo que mostram a sua
estória e trazem as informações sobre os sintomas da dengue. O jogo tem uma fase
que traz os principais criadouros como inimigos do jogo.
O processo de desenvolvimento foi realizando usando metodologia Scrum de
forma adaptada sendo que esse processo foi divido em cinco Sprints sendo eles:
Gerenciamento de cenas e menu inicial;
Criação do cenário, integração da engine xTile, carregamento e
manipulação do cenário;
Integração da Farseer Physics Engine para gerar física e detecção de
colisões no jogo, implementação da animação e física dos
personagens e geração da física onde é possível o jogador se
movimentar;
Implementação da animação e física dos inimigos, codificação das
respostas às colisões dos inimigos com o cenário, do jogador com os
inimigos e implementação da Hud;
Sistema de pausa, detecção de fim e sons do jogo.
Os Sprints são definidos com base no product backlog, que contém todos os
itens que devem ser desenvolvidos do jogo. São selecionados itens de acordo com a
42
sua prioridade. Essa prioridade reflete uma ordem para que se possa incrementar o
jogo e no final tê-lo por completo.
No product backlog além da prioridade tem uma estimativa de tempo para se
concluir cada item e então selecionar uma quantidade de itens que não ultrapasse o
tempo máximo dos Sprints, que são de quatro semanas. Na Tabela 7 apresenta-se o
product backlog do jogo.
Tabela 7 – Product backlog
Product Backlog id Descrição Prioridade Estimativa (Dias)
1 Adicionar sons ao jogo 6 14
2 Adicionar a Hud a fase 9 5
3 Criar a animação dos inimigos 12 2
4 Criar Menu Inicial 19 4
5 Desenvolver os scripts de animação de personagem 14 6
6 Fazer integração da engine Farseer Physics 16 8
7 Fazer integração da engine xTile 17 8
8 Fazer o carregamento do Cenário feito com tIde 17 2
9 Implementação de sistema de pausa do jogo 8 7
10 Colisões entre jogador e inimigos 10 5
11 Tela final com a contagem de pontos 7 7
12 Scripts do Gerenciamento de Cenas 20 10
13 Colocar física onde o jogador vai se movimentar 15 5
14 Colocar física nos personagens 13 2
15 Colocar física nos inimigos 11 2
16 Criar cenário do jogo 18 4
Fonte: Próprio autor (2012).
6.1 Primeiro Sprint
Nesse Sprint foram selecionados os itens 12 e 4 do product backlog, tendo
como objetivo final o gerenciamento de cenas do jogo e o menu inicial do jogo.
Assim que é criado um novo projeto de jogo é também criada
automaticamente uma classe que contem o código básico para o jogo funcionar,
chamada de Game1. Essa classe é onde se inicia o jogo. Ela tem métodos para
carregar recursos como imagens, descarregar recursos e o game loop. Esse é o
43
loop que trata de ler os dispositivos de entradas, atualizar o jogo e, por último
desenhar o jogo na tela. Na Figura 22 é apresentada parte dessa classe. Nessa
parte encontra-se o método Update onde é atualizado o jogo e o método Draw,
responsável por desenhar na tela.
Figura 22 – Classe Game1.
Fonte: Próprio autor (2012).
Para o gerenciamento de cenas foi criada uma classe abstrata chamada
Scene mostrada na Figura 23, que é uma classe que contém métodos que classes
filhas dela são obrigadas a ter. Ela tem a finalidade de ser a base para todas as
cenas. Assim, todas as cenas que o jogo tiver é uma nova classe filha da Scene. Ela
tem os métodos Update e Draw que são necessários para todas as cenas.
Figura 23 – Classe Scene
Fonte: Próprio autor (2012).
44
Na classe Game1 foi criado um método responsável por trocar de cenas. É ele
quem carrega a cena inicial e troca a cena quando necessário. A partir desse ponto,
está pronto o gerenciamento de cenas.
O próximo passo desse Sprint é o menu inicial, uma cena do jogo. Para ele foi
criada uma classe filha de Scene chamada Menu. Ela funciona desenhando na tela
um menu com escolha para o jogador, sendo possível escolher jogar e sair. Ela
inicia com o item “jogar” marcado, ou seja, o jogador movimenta as setas para
esquerda ou direita para mover a seleção do item de menu e tecla enter para
selecionar. Terminado esse Sprint, o jogo está com o gerenciamento de cenas e o
menu inicial funcionando. A Figura 24 apresenta o menu.
Figura 24 – Resultado do primeiro Sprint
Fonte: Próprio autor (2012).
6.2 Segundo Sprint
Nesse Sprint é criado o cenário, feita a integração do jogo com a engine xTile,
que faz o carregamento e manipulação do cenário, que são os itens 16, 7 e 8 do
product backlog, tem como resultado final, o jogo com a fase em execução.
O cenário foi criado usando a técnica de Tilemap, que consiste em criar uma
imagem completa usando pequenos pedaços de imagem, assim compondo
45
camadas que formam o cenário. Na Figura 25 temos o editor de cenário da xTile,
chamando tIde Tile Map Editor.
Figura 25 - tIde Tile Map Editor.
Fonte: Próprio autor (2012).
Para integrar a xTile adicionaram-se ao projeto do jogo duas DLL’s que
contêm toda a engine. O cenário é uma cena de jogo, então se cria uma classe filha
de Scene.
Para usar o xTile no jogo deve-se configurar três parâmetros: o cenário do
jogo, o dispositivo de desenho e o viewport, que é a parte do cenário que é
desenhada e visível na tela. Na Figura 26 é mostrada a parte do código que contêm
esses parâmetros.
Figura 26 – Parâmetros xTile
Fonte: Próprio autor (2012).
46
Para movimentar o cenário de acordo com o movimento do jogador basta
incrementar ou decrementar a posição horizontal do viewport. Isso é feito no método
Update dessa cena e para desenhar usa-se o método Draw da propriedade map da
cena de jogo. Com o final dessa etapa, obtêm-se a integração, o carregamento e a
manipulação do cenário feito. Na Figura 27 é mostrada a fase em execução.
Figura 27 – Resultado do segundo Sprint
Fonte: Próprio autor (2012).
6.3 Terceiro Sprint
Nesse clico foi realizada a integração da engine Farseer Physics Engine com
o jogo, adicionada física nas partes do cenário em que é possível andar, a
codificação da animação e física do personagem, que são os itens 5, 6, 13 e 14 do
product backlog.
Para a integração desta engine adicionou-se o seu projeto ao projeto do jogo.
O funcionamento dela é através de um “mundo”, onde toda a física e colisão
acontecem. A partir desse mundo criado adicionam-se os objetos como, por
47
exemplo, quadrados e círculos. Assim, eles sofrem ação da física e podem colidir,
tendo métodos para tratar as reações às colisões.
Para que o personagem e os inimigos possam andar no cenário foi preciso ler
uma camada que representa o “solo” e criar quadrados da engine Farseer Physics.
Assim esse caminho obteve física e o personagem pode andar sobre o solo. Na
Figura 28 observa-se na linha 74 a criação do mundo, onde acontece a física e, na
linha 75, a definição da força da gravidade desse mundo.
Figura 28 – Criando o mundo da Farseer Physics
Fonte: Próprio autor (2012).
A animação do personagem consiste em se ter uma imagem que contém
sequencias de quadros que representam ações, como andar e pular, para que seja
feita a troca de quadros a cada certo tempo e assim criar a animação. Para a física
do personagem foi criado um corpo composto de um círculo para os pés e um
quadrado representando o restante do corpo. Para essas implementações foram
criadas duas classes, uma representa a sequência da animação chamada de
Animação e outra chamada de SpriteAnimado que recebe as animações e tem a
lógica para executa-las. Nela também está a física do personagem.
Terminado esse Sprint, temos o mundo da engine Farseer Physics Engine
realizando a simulação de física, os quadrados físicos da parte do cenário que
representam o solo, a animação do personagem e sua física. Na Figura 29 é
mostrado o resultado desta Sprint.
48
Figura 29 – Resultado do terceiro Sprint
Fonte: Próprio autor (2012).
6.4 Quarto Sprint
Para esse Sprint foram selecionados os itens 2, 3,10 e 15, que correspondem
a criar animação para os inimigos, adicionar física a eles, programar a reação das
colisões entre inimigo e cenário, do jogador com inimigos e criar a Hud para o jogo.
A animação e a física dos inimigos são feitas da mesma forma que a do
personagem. Assim, foi usada a mesma classe base e criada uma classe filha
chamada Inimigo, pois se difere do personagem em alguns pontos. Essa diferença
está na lógica para fazer os inimigos perambulem pela fase e, quando colidirem com
alguma parte do cenário, mudarem o sentido em que estão andando.
O tratamento de colisões entre jogador e inimigos foi implementado em um
método da classe Jogador. Nesse método, quando o jogador colide com um inimigo
verifica-se a posição vertical (posição y na engine), do jogador, se esta posição
estiver acima do inimigo quer dizer que ele colidiu sobre ele, e então se opera a
49
morte do inimigo e a soma de pontos para o jogador. Caso contrário, quem morre é
o jogador e é tirada uma vida dele.
Para a Hud existe a classe chamada Hud, essa classe recebe a largura da
tela e um valor de distância que se deseja deixar as informações do topo da tela.
Com isso, ela desenha as informações de nome da fase, vidas e pontos. O nome da
fase fica no canto esquerdo, as vidas no centro e os pontos à direita, todos na
mesma altura definida.
Após essa etapa, o jogo conta com os inimigos no cenário, a Hud e as
respostas às colisões entre jogador e inimigos. A Figura 30 apresenta a fase após
essa etapa.
Figura 30 – Resultado do quarto Sprint
Fonte: Próprio autor (2012).
6.5 Quinto Sprint
Nesse Sprint são selecionados os itens 9, 11 e 1, que são relacionados ao
sistema de pausa, a detecção de fim e sons do jogo.
50
O sistema de pausa consiste em detectar se o jogador pressionou “Esc” ou “p”
e assim ele pausa o jogo e mostra um menu de pausa, com as opções de continuar
e sair. Assim que o jogador pausa, o jogo passa para a atualização e desenho do
menu de pausa. Isso mantém o jogo parado para continuar do mesmo ponto, caso o
jogador escolha continuar. Na Figura 31 é mostrado o menu de pausa.
Figura 31 – Menu de pausa
Fonte: Próprio autor (2012).
Para finalizar o jogo foi criado um item que fica no final da fase, onde termina
o cenário e, através da colisão do personagem com esse item, é terminado o jogo e
carregada a cena final. Essa detecção de colisão é feita no próprio jogador. A cena
de final de jogo mostra a pontuação do jogador, quantos inimigos ele matou e, se
eliminou todos, ganha um bônus na pontuação. O texto com essas informações
aparece linha por linha em um intervalo de tempo de dois segundos e após a
pontuação é mostrado a tela final do jogo que mostra ao jogador que ele deve
retransmitir o conhecimento sobre o combate à dengue. Nas Figuras 32 e 33 são
apresentadas a pontuação do jogador e a tela final.
51
Figura 32 – Pontuação
Fonte: Próprio autor (2012).
Figura 33 – Tela final
Fonte: Próprio autor (2012).
52
Como último passo desse Sprint foram adicionados sons para o jogo. Os sons
são executados quando o jogador pula, quando ele mata o inimigo e quando ele
morre. Além desses sons, tem uma música que inicia quando o jogador começa a
jogar e fica tocando enquanto estiver jogando.
Após a conclusão desse último Sprint, todos os itens do product backlog
foram realizados, tem-se o desenvolvimento do jogo terminado e uma versão final
liberada. A partir desse ponto podem-se realizar melhorias no jogo e também
realizar correções de bugs que possam surgir.
53
7 CONSIDERAÇÕES FINAIS
Como apresentado a dengue é uma doença problemática que é contraída por
muitas pessoas e traz risco de morte. Seu controle é difícil e necessita da
participação de todos. O método mais efetivo de enfrentar a doença é o combate
aos criadouros do mosquito da dengue, com a participação de todos, sendo assim é
importante ter ferramentas para criar conscientização sobre a importância da
participação de todos.
Este trabalho mostra que os serious games são uma ferramenta diferenciada
para o ensino e transmissão de conhecimento. Eles são usados por diversos setores
que cada vez mais comprovam o seu valor. Este trabalho resultou em um jogo para
computador para transmitir conhecimento sobre o combate à dengue e trazer maior
conscientização. Ele tem ênfase nos criadouros do mosquito, por ser o principal
método de combate à dengue. Como forma de mostrar ao jogador que deve
combater os criadouros, os inimigos no jogo são os próprios criadouros do mosquito
da dengue. Este jogo vem ser uma ferramenta para ajudar na conscientização do
combate à dengue.
O jogo foi desenvolvido com o Framework XNA e a linguagem C# por ser um
framework feito para o desenvolvimento de jogos trazendo facilidades para o
desenvolvedor. O jogo é para computadores com Windows e será distribuído
gratuitamente através da Internet, com a intenção de ter maior alcance às
comunidades mais suscetíveis à doença.
7.1 Trabalhos futuros
A seguir, são apresentadas sugestões para continuidade deste trabalho:
Melhorar a arte do jogo;
Desenvolvimento de novas fases para o jogo ter maior duração e mais
desafios;
Acrescentar inimigos “chefes” para aumentar o desafio;
54
Adicionar mais inimigos, que representem outros locais utilizados como
criadouros, mas que não são os principais.
Essas medidas visam aumentar assim os desafios e diversão, para ter maior
engajamento dos jogadores.
A aplicação deste jogo em uma escola com dois grupos de alunos, em que um
grupo utilize o jogo e outro tenha uma aula sobre, para assim poder avaliar a eficácia
do jogo em relação à aula.
55
REFERÊNCIAS
Atari. Battlezone. Disponível em: http://www.atari.com/battlezone. Acesso em 26 mai 2012. Centro Universitário Salesiano de São Paulo. XII Mostra de Produção Científica. Campinas, 2012. Cruz, Dulce Márcia; Albuquerque, Rafael Marques de; Azevedo, Victor de Abreu. Jogando e aprendendo nos mundos virtuais. Disponível em: http://www.labomidia.ufsc.br/index.php?option=com_docman&task=doc_details&gid=24&Itemid=60. Acesso em: 12 mai 2012. Cruz, Dulce Márcia; Ilha, Paulo César Abdalla. Brincando e aprendendo nos mundos virtuais: o potencial educativo dos games de simulação. Comunicação & Educação, ano XIII, n° 2. Deemer, Peter; Benefield, Gabrielle; Larman, Craig; Vodde, Bas. The Scrum Primer. Disponível em: http://assets.scrumfoundation.com/downloads/1/scrumprimer121.pdf?1294640838. Acesso em: 22 abr 2012. Fowler, Martin. UML Essencial Um breve guia para a linguagem-padrão de modelos de objetos 3 edição. Bookman, 2005. Ghensev, Rogério. O USO DOS GAMES NA EDUCAÇÃO. 2010. 55f. (Pós-graduação em Mídias Interativas) - CENTRO UNIVERSITÁRIO SENAC, São Paulo, 2010. Marsh, Tim. Serious games continuum: Between games for purpose and experiential environments for purpose, Entertainment Computing, Volume 2, Issue 2, 2011, Pages 61-68, ISSN 1875-9521, 10.1016/j.entcom.2010.12.004. Disponível em: http://www.sciencedirect.com/science/article/pii/S1875952110000224. Acesso em: 15 abr 2012. Michael, David; Chen, Sande. Serious Games: Games That Educate, Train and Inform. Thomson Course Technology, 2006.
56
Microsoft. XNA Framework Overview. Disponível em: http://social.technet.microsoft.com/wiki/contents/articles/xna-framework-overview.aspx. Acesso em: 05 mai 2012. Ministério da Saúde. Cartilha da Dengue. Disponível em: http://www.saude.sp.gov.br/resources/ses/perfil/cidadao/orientacao/cartilha_da_dengue.pdf. Acesso em: 20 fev 2012. Ministério da Saúde. Diretrizes Nacionais para a Prevenção e Controle de Epidemias de Dengue. Brasília: Ministério da Saúde, 2009. Ministério da Saúde. Portal da Saúde. Disponível em: http://portalsaude.saude.gov.br/portalsaude. Acesso em: 19 fev 2012. Montain Goat Sotware. An Overview of Scrum for Agile Software Development. Disponível em: http://www.mountaingoatsoftware.com/scrum/overview. Acesso em: 28 abr 2012. Nintendo Blast. Revista Nintendo Blast n° 6, GameDev. Disponível em: http://www.nintendoblast.com.br. Acesso em : 05 mai 2012. Object Management Group. Introduction to OMG's Unified Modeling Language. Disponível em: http://www.omg.org/gettingstarted/what_is_uml.htm. Acesso em: 19 mai 2012. Pressman, Roger S. Engenharia de Software. 6a edição. McGraw-Hill, 2006. Schwaber, Ken; Sutherland, Jeff. The Scrum Guide The Definitive Guide to Scrum: The Rules of the Game. Scrum.org, 2011. Sindicato das Entidades Mantenedoras de Ensino Superior. 12° Congresso Nacional de Iniciação Científica. São Paulo, 2012. Star Wars: Episódio V - O Império Contra-Ataca. Kershner, Irvin. EUA: Lucasfilm, 1980. Superdownloads. America's Army - Deploy 3.1.1. Disponível em: http://www.superdownloads.com.br/download/102/americas-army-deploy/. Acesso em: 11 nov 2012.
57
Susi, Tarja; Johannesson, Mikael; Backlund, Per. Serious Games - An Overview. Technical Report HS- IKI -TR-07-001, School of Humanities and Informatics. University of Skövde, Sweden, 2007. Wilson, Greg. Off With Their HUDs!: Rethinking the Heads-Up Display in Console Game Design. Gamasutra, 2006. Disponível em: http://www.gamasutra.com/view/feature/2538/off_with_their_huds_rethinking_.php. Acesso em: 19 mai 2012. World Health Organization. Dengue and severe dengue. Disponível em: http://www.who.int/mediacentre/factsheets/fs117/en/index.html. Acesso em: 21 fev 2012a. World Health Organization. Dengue control. Disponível em: http://www.who.int/denguecontrol/en/index.html. Acesso em: 03 mar 2012b. World Health Organization. Dengue, países ou áreas de risco, 2011. Disponível em: http://gamapserver.who.int/mapLibrary/Files/Maps/Global_DengueTransmission_ITHRiskMap.png Acesso em: 03 mar 2012c. Yasumaro, Sueli; Sabbo, Cristina; Ciaravolo, Ricardo Mário; Ferreira, Lúcia de Fátima Henriques; Taveira, Lúcia Antonia; Moura, Liane Cursino de; Glasser, Carmen Moreno. Guia Básico de Dengue. Superintendência de Controle de Endemias de São Paulo, 2002. Disponível em: http://www.saude.sp.gov.br/resources/ses/perfil/cidadao/orientacao/guia_basico_de_dengue_.pdf. Acesso em: 20 fev 2012.
58
ANEXO A – Certificado de participação no 12º Congresso Nacional de Iniciação
Científica CONIC-SEMESP
Fonte: Sindicato das Entidades Mantenedoras de Ensino Superior (2012).
59
ANEXO B – Painel apresentado no 12º Congresso Nacional de Iniciação Científica
CONIC-SEMESP
Fonte: Próprio autor (2012).
60
ANEXO C – Certificado de participação na XII Mostra de Produção Científica
UNISAL
Fonte: Centro Universitário Salesiano de São Paulo (2012).
61
ANEXO D – Painel apresentado na XII Mostra de Produção Científica UNISAL
Fonte: Próprio autor (2012).