PauloMotta.pro

O dicionário Houaiss nos diz que colisão é “embate entre dois ou mais corpos; choque.” Para jogos de computador isso é muito importante porque é a base de qualquer interação. Para começar precisamos entender que um jogo de computador (ou eletrônico) é simplesmente um programa de computador com uma interface “desenhada.”

É aí que entra a importância da colisão, se você desenha várias coisas na tela e o usuário usa o mouse para escolher alguma coisa precisamos descobrir em quê o usuário clicou. Em uma aplicação tradicional de sistemas de informação geralmente contamos com uma biblioteca (normalmente ampla) de componentes gráficos tais como caixas de texto, botões, caixas de seleção e por aí vai. Quando programos um jogo usamos bibliotecas de desenho mais voltadas para itens gráficos e menos para a interação do usuário, principalmente quando o jogo está em andamento.

O primeiro problema que surge é que as pessoas acham que a colisão tem a ver com o conceito que aprendemos nas aulas de física, quando isso é uma verdade parcial. Em jogos a colisão está divida em duas etapas, a primeira é identifica que ela aconteceu e a segunda é tomar alguma decisão, ou seja, reagir. Se estivermos fazendo um jogo de pinball por exemplo a colisão precisa de suporte baseado no que aprendemos em física, a bola tem que quicar e ser rebatida. Por outro lado se estivermos fazendo um jogo estilo acerte-o-seja-lá-o-que-quisermos-colocar-na-tela (zumbis, baratas, mosquitos…) então a colisão nada tem a ver com física apenas identificar em que item o jogador bateu sua raquete.

Mas como fazer isso então ? Elementar meu caro watson !

Primeiro passo: tenha uma estrutura de dados que contém os itens que aparecem na tela, por exemplo um vetor com todos os objetos “acertáveis”. Além disso temos que saber a posição de cada um desses itens.

Segundo passo: desenhe alguns desses itens na tela, é nessa hora que sabemos onde eles estão.

Terceiro passo: leia a entrada do usuário. Isso significa um (ou talvez mais) pontos x,y (isso para um jogo 2D)

Quarto passo: teste se a posição x,y que o usuário marcou esta “dentro” de algum dos itens que estava aparecendo.

Ok, na teoria isso é muito mais fácil do que parece, mas também não é nada do outro mundo. Existem diversos algoritmos para identificar a colisão e o mais simples de todos é o bounding box (retângulo, ou caixa, limitante) imaginamos que para cada item aparecendo na tela existe um retângulo ao redor desse item. Assim, para saber se alguma coisa está colidindo com esse elemento precisamos testar o seguinte:

Considere um retângulo qualquer que tem como coordenadas x1,y1 para o canto superior esquerdo e x2,y2 como canto inferior direito. Considere ainda que a entrada do usuário é o ponto xu,yu. O ponto colide se:

xu>=x1    E     xu<=x2  E  yu>=y1  E  yu<=y2

Se essa fórmula for falsa então o usuário não clicou nesse item.

Agora precisamos saber quando esse teste tem que ser executado, sim! porque o momento em que isso será feito é fundamental. Todo jogo precisa ter o que chamamos de game-loop, ou laço do jogo, podemos entender isso como as iterações do programa para redesenhar a tela, daí inclusive vem a questão de FPS (frames per second, quantos quadros por segundo) quanto melhor a arquitetura do nosso jogo mais frames poderemos desenhar por segundo.

Se fizermos o teste de colisão fora do game-loop o que vai acontecer é que poderemos perder “tiros certos,” e aí alguém diz “mas hein?” Explico, o game-loop em algumas plataformas é feito com uma thread a parte da entrada de usuário, assim os itens vão sendo desenhados de forma independente, isso é ótimo, porém enquanto estivermos testando todas as colisões as posições podem ser alteradas, então se fizermos esses testes dentro do game-loop o jogo vai sendo “atrasado” de forma que as coisas só têm suas posições alteradas depois de todos os testes terem sido realizados. E é por isso que é importante que o algoritmo de colisão seja muito rápido.