3D Simulado

Apesar de a engine utilizada pela equipe para o "Matt" Sniper ser a Chien2D, desenvolvida por professores da PUC-PR, decidimos fazer um jogo em primeira pessoa, simulando um ambiente 3D como parte da estratégia de buscar com que o jogo capture o usuário dentro de um clima tenso e sóbrio.

Para que isso fosse possível, a primeira decisão foi que cada fase do jogo teria uma única vista, que não poderia ser rotacionada. Afinal de contas, não podemos esquecer que estamos trabalhando numa plataforma 2D, sem contar o volume de modelagem, programação e arte necessários para fazer um 3D completo, algo completamente fora do escopo do projeto e do período de tempo disponível.

A partir de aqui, utilizaremos a segunda fase do jogo - constituída numa missão em cenário urbano - para ilustrar nossa implementação. Eis como procedemos:

1) Modelo 3D do cenário Um modelo construído dentro do programa 3D Studio Max foi gerado e renderizado, constituindo-se na visão do jogador. Matt se encontra 54 metros acima do solo e a uma distância dos elementos do cenário tipicamente em torno de 100-250 metros.

Figura 1: Cenário 1 - versão final

2) Tamanho dos objetos móveis do cenário Escolhemos pontos de referência dentro do modelo, tomando suas coordenadas tridimensionais e suas coordenadas de tela para construir uma relação de variação do tamanho dos objetos de acordo com sua posição na tela. Dessa forma, um personagem que caminha ao longo da rua da esquerda na imagem abaixo, por exemplo, torna-se cada vez maior à medida que "desce a tela", aproximando-se do atirador. E o efeito contrário à medida que se afasta do atirador.

Figura 2: O personagem torna-se maior ao aproximar-se do sniper


3) Passando por trás e pela frente de objetos Um ponto muito importante para manter a impressão de um cenário tridimensional foi a possibilidade de objetos móveis - como pessoas - poderem contornar estruturas do cenário, como prédios. Assim, de acordo com a posição das pessoas na tela, elas poderiam estar ou não ocultadas por prédios, muros ou outros elementos.

Como foi feito: a) Foram armazenadas imagens separadas para cada elemento do cenário atrás do qual existisse a possibilidade de passagem de algum objeto. b) Armazenou-se uma lista com as coordenadas de tela desses elementos que definiam a partir de onde um objeto estaria atrás ou na sua frente. c) De posse dessa lista, um algoritmo controlou a sequência de renderização de cada elemento móvel e do cenário na sequência correta (se uma pessoa deveria estar atrás de um prédio, ela foi renderizada antes do prédio, e vice-versa).


Figura 3: Cortes (picotes) do cenário. As figuras mostradas aqui em destaque são renderizadas antes ou depois de um personagem, dependendo da posição deste último



4) Pessoas atravessando paredes é crime contra as leis físicas (e ninguém venha nos falar de tunelamento quântico!) Por fim, julgamos importante que o programa detectasse uma colisão dos elementos móveis do cenário com muros e prédios. Esta etapa poderia ser pulada se simplesmente limitassemos os movimentos das pessoas no cenário de forma que jamais tocassem muros ou prédios. Decidimos por não adotar essa limitação pelo fato de que levaria a i) movimentos muito simples por parte das pessoas, o que cortaria todo o clima com o qual nos comprometemos desde o início; ou ii) uma carga de trabalho para fazer movimentos que parecessem plausíveis tão grande... que nos arrependeríamos de não haver montando uma estratégia para detectar a colisão das pessoas com prédios e muros. De fato, a solução que criamos não foi complicada.

Como foi feito: a) criamos uma imagem semelhante à do cenário, mas com todas as partes acessíveis às pessoas pintadas em magenta (a cor padrão de transparência da Chien2D). b) Criamos um sprite com essa imagem. c) a Chien2D já tem implementada a colisão pixel-a-pixel (perfect pixel collision) entre sprites, portanto, quando detectada uma colisão, impedimos o personagem de seguir adiante.