O objetivo do jogo é fazer o personagem passar despercebido pelo labirinto, evitando ser descoberto
pelas câmeras ou outros obstáculos contidos nas fases. Para a concepção do jogo utilizamos a
ferramenta Construct 2, uma engine bastante intuitiva de código aberto criado pelo grupo Scirra, ele
também usa o Python como linguagem de script para complementar os jogos.

Para a construção do jogo nos baseamos em um ambiente hostil, onde o personagem se sinta
preso, algo semelhante a uma prisão, mas com muitas armadilhas até a saída. Também utilizamos
uma música frenética para dar mais sensação de urgência ao jogador.

O jogo é um apk para Android e seus comandos são touch screen, onde o jogador poderá andar pelo cenário, mas se for detectado um alarme soa e o jogo é finalizado. Caso o personagem
encoste em alguma das diversas armadilhas do cenário ele recebe um dano e o jogador tem um
feedback com um efeito sonoro, se o jogador fizer o personagem levar três danos o jogo é finalizado
e o jogador recebe um feedback com uma animação do personagem.

O jogo contém uma tela inicial contendo o logotipo da equipe de desenvolvimento, seguido da tela
do menu que possui a opção de iniciar o jogo, consultar o ranking ou finalizar. O ranking é medido
pelo tempo que o jogador leva para finalizar a fase.

O cenário do jogo é pré-definido e as armadilhas estão em pontos estratégicos para aumentar a
dificuldade para o jogador prosseguir. Elas funcionam mecanicamente e existe um loop de repetição.
O personagem é composto de sprites que definem sua animação de acordo com a posição em que
o jogador está sendo controlado. Todos os sprites estão no formato *.PNG. Os arquivos de áudio
são trilhas do formato *.OGG, arquivos que são suportados pelo Construct 2. As representações
gráficas de cenário e partículas estão em imagens no formato *.PNG ou *.JPG.

Conceitos envolvidos

No desenvolvimento de nosso jogo utilizamos uma engine própria para jogos, chamada Construct 2. Essa engine utiliza o HTML5 + Javascript para dar vida aos seus jogos e é bem simples de aprender. Para desenvolver nosso jogo utilizamos vários conceitos de mecânica para que o gameplay fosse fluído e agradasse o jogador.
Acredito que o conceito envolvido que é mais presente no jogo é a colisão. Através da colisão conseguimos criar um jogo que pode ser comparado com Pac-Man. A colisão está presente em praticamente todas as mecânicas de jogo, como por exemplo: O jogador colide com a parede, impedindo que ele as ultrapasse como um fantasma, todas as barreiras impostas ao jogador são feitas com colisão: barras de metal deslizando rapidamente, chamas sendo atiradas e as câmeras de vigilância, o jogador só pega o item colidindo com ele e só para de fase colidindo com o final.
Toda a parte de colisão pode ser mapeada no Construct 2 e facilitou o processo de desenvolvimento.

Utilização desses conceitos durante o desenvolvimento

O jogador controla o personagem principal, que tem toda sua área de colisão mapeada na engine. Para deixar o gameplay fluído, mapeamos as áreas de colisão de todos os objetos do jogo e apenas aplicados algum tipo de movimento simples neles. Dessa forma, garantimos que as mecânicas do jogo trabalhem praticamente sozinhas e o jogo seja arquitetado de forma natural. Por exemplo:
Temos em nossa biblioteca de itens a câmera. Esta câmera realiza um movimento na quantidade de graus que nós definimos (geralmente 90 ou 180 graus) e fica se movimentando infinitamente nesse padrão, de um lado para o outro. Se o jogador entra em contato com sua linha de visão (colisão) um alarme é acionado, acabando com o jogo.
Outro exemplo são as barras de metal. Elas se movimentam infinitamente de um lado para o outro, mas ao contrário da câmera ela só se move para uma direção (horizontal ou vertical).
Dessa forma garantimos que no fim do desenvolvimento, tivéssemos um modelo pronto de jogo. E que só a “modelagem” das fases fosse necessária.

Problemas resolvidos


Ausência de um controle para o jogador

O Construct 2 possui uma funcionalidade muito interessante chamada “behaviors”. Behaviors são
comportamentos que você atribui a qualquer coisa no jogo para que ele possua algumas
funcionalidades relacionadas àquele behavior especifico. Por exemplo, o behavior “bullet” faz com
que o objeto ande em linha reta infinitamente, atribuído para balas de uma arma, como o nome
sugere, por exemplo.

Quando começamos a trabalhar com o Android, estávamos realizando os testes com um behavior chamado “8 direction” que atribuía automaticamente para as quatro setas do teclado o controle do personagem. Porém, nós queríamos desenvolver esse jogo para os celulares, e eles não possuem um teclado.

Para contornar esse problema, “emulamos” um controle na tela do jogo, que fica disponível no canto inferior esquerdo da tela. Esse controle emula um teclado no jogo, fazendo com que o personagem se desloque 5 pixels na direção que o jogador tocar.


Uma barra de vida

Quando desenvolvemos o jogo, criamos uma variável local chamada “vida” (integer) que calculava a vida que o jogador possui durante a jogatina. O jogador começa com 5 pontos de vida (variável declarada com o valor 5) e quando a vida chega à zero, ele morre. Apesar da mecânica estar funcionando normalmente, o jogador não tem esse feedback, e consequentemente, não sabe quando irá morrer, o incentivando a não ter cautela.

Para desenvolver uma barra de vida, fizemos o seguinte: criamos um objeto chamado “barraDeVida” no projeto com 6 animações. Cada animação representa um estado de vida, desde vida cheia (5 barrinhas) até vida vazia (0 barrinhas).

A barra de vida ficou “ancorada” na tela do jogo, no canto superior esquerdo da mesma. A todo segundo, o jogo realiza uma verificação na variável “vida” e, de acordo com seu valor, seta a animação da barra de vida para a animação adequada. Por exemplo: se “vida” for igual à 4, o sistema irá identificar isso e irá trocar a animação da “barraDeVida” para a animação de 4 barrinhas.

Lentidão no Mini PC e nos celulares

Quando começamos a realizar os testes no Mini PC, identificamos que o jogo estava rodando com extrema lentidão. Depois de corrigirmos algumas coisas em nosso código afim de melhorar a performance do jogo, o testamos novamente. A performance melhorou, mas não consideravelmente.

Fomos atrás de alguma solução em fóruns e tópicos espalhados pela internet para encontrar alguém com o mesmo problema que o nosso. Conseguimos identificar a função delta-time do Construct 2, que auxiliou de forma extrema a mantermos uma taxa de frames por segundo estável para que o jogo fosse executado de acordo com a plataforma e o hardware.

Dessa forma, em alguns aparelhos mais modestos, o jogo não possui tantos detalhes, porém roda a 30 frames por segundo. O mesmo ocorre com aparelhos mais potentes, porém o jogo possuirá mais detalhes. Com o delta-time aplicado em algumas funções do jogo, conseguimos deixar o jogo estável em qualquer plataforma.

Home
<< Back Next >>