A borda nada mais é que um delimitador da área do jogo, que pode ser os extremos da tela, por exemplo.

Esta detecção é importante caso seja necessário manter um sprite dentro da tela. Por exemplo, nos jogos de tiro em scroll vertical como a série Sonic Wings, você não consegue movimentar o avião além da própria tela. Quando o aviãozinho atinge o limite da tela, ele simplesmente não se locomove mais naquela direção.

Utilizando a classe Sprite criada no post anterior, podemos chamar uma função que retorne um booleano para detecção de colisão para uma determinada borda. Quando o retorno for true, o que podemos fazer é zerar a velocidade naquela direção, e talvez voltar um pixel para que o sprite saia do estado de colisão e não fique "preso".

Uma coisa que eu esqueci de mencionar no post anterior é que para que possa ser detectado com facilidade as colisões, o ideal é usarmos sprites retangulares. O problema é que um Super Mario quadradinho não venderia tão bem...

Para contornar este problema, devemos sempre usar, associado à imagem do sprite, um retângulo invisível que servirá de zona de detecção. Quando mais ajustado ao tamanho da imagem, melhor.

A classe Sprite possui um objeto pictureBox dentro dela, e esse pictureBox possui a imagem do sprite, e além disso, ela é um retângulo cujas dimensões podem ser facilmente obtidas. Ou seja, o próprio pictureBox serve tanto como imagem quanto zona de detecção. Se fosse no XNA puro, teríamos que renderizar a imagem em cima de uma retângulo invisível e usar a imagem para exibição, e o retângulo para detecção.

Fugindo um pouco, mas nem tanto... Vocês já perceberam que nos primeiros Resident Evil as imagens que formam os cenários são navegáveis pelos personagens como se fossem 3D? Como o jogo sabe numa imagem onde começa o corredor ou onde está a porta? É simples. O jogo não sabe. Os programadores posicionam em cada imagem do cenário um cubo de detecção exatamente com as dimensões das áreas "caminháveis" de cada imagem. E é por este cubo invisível que a engine do jogo se enxerga para deslocar os personagens. A foto não influencia em nada.

Possíveis bordas feitas por mim

No caso do nosso sprite, até seria possível ficar testando a sobreposição de imagens, pixel a pixel, para proporcionar uma colisão perfeita. Mas se fizessem isso com Mario, ele nunca rodaria nos consoles antigos. Lembram que eu mencionei sobre uma detecção de colisão que eu fiz comparando pixel a pixel os retângulos? Nem usei os pixels da imagem, que certamente pesaria mais ainda, e ainda assim o jogo ficou com uns 5 quadros.

Em imagens mais complexas, são utilizados mais retângulos por sprite, e as colisões são testadas individualmente. Um exemplo disso são os jogos de luta 2D. Quem já fuçou no MUGEN já deve ter visto isso.

Voltando à colisão de borda, temos que testar a colisão de cada borda individualmente. Para isso, basta chamar a função para cada borda que deve ser testada, passando o limite dela, o sprite, e a direção.

Para criar a função, eu criei também um enumerador com as quatro direções, e assim fica mais fácil passar a direção como parâmetro.

Para cada direção, eu uso um dos vértices do retângulo do sprite para testar a colisão. Eu criei para a classe Sprite quatro propriedades para retornar cada vértice do retângulo, começando a partir do superior esquerdo (0,0) e girando no sentido horário:

Para testar uma colisão do lado esquerdo, preciso usar o vértice 1 ou o 4.

Para testar uma colisão em cima, preciso usar o vértice 1 ou o 2.

Para testar uma colisão do lado direito, preciso usar o vértice 2 ou 3.

Para testar uma colisão embaixo, preciso usar o vértice 4 ou 3.

Todos os sprites ocupam uma posição absoluta na tela. A tela nada mais é que uma grade de pixels, que começa no canto superior esquerdo como 0,0, e termina no canto inferior direito como 640,480 (caso esteja usando esta resolução).

Então, se o vértice 1 estiver na posição do eixo X=0 ou menos, houve uma colisão do lado esquerdo. Se não pararmos o sprite neste momento, nada impede que ele saia da área visível da tela. É perfeitamente possível um sprite ocupar coordenadas de valores negativos (-52,300).

Vamos à função:

Uma função extremamente simples e leve. Se quisermos testar a colisão nos quatros lados da tela, teremos que chamar a função 4 vezes. Para cada vez, passamos uma das direções e o limite da borda, em pixels. Na colisão à esquerda, o collisionPoint deve ser 0. Para a colisão à direita, o collisionPoint deve ser 640.

O que será feito com o retorno da função depende de cada game ou situação. No WinForms Lander, só testo a colisão na parte de baixo. Caso haja colisão, a nave quebra, o jogador perde uma vida, e o estágio é reiniciado. Só passa de fase se o jogador pousar na plataforma.

Parte 7 - Final

Existem muitas implementações para colisão. Desde implementações simples até das mais complexas. Por exemplo, a colisão usada nos jogos do Mario para coletar as moedas só precisa informar se Mario tocou a moeda. Mas para testar a colisão em um koopa, é necessário verificar se Mario está acima ou no lado ao tocar o inimigo. Caso esteja em cima, Mario sai ileso e elimina o inimigo. Caso esteja no lado, Mario perde uma vida.

Para testar uma colisão dessas, é bem mais complicado. Principalmente se os sprites se movem com mais velocidade.

O que vou mostrar agora é a colisão simples (aquela da moeda). Até porque a minha colisão que detecta a direção do toque não é 100% confiável em altas velocidades (parece até coisa de mecânica quântica). Eu digo "minha" colisão porque fiz questão de tentar criar uma solução por conta própria, sem pesquisar nada na internet. É claro que futuramente terei que ir atrás disso, pois não sou um bom programador de jogos e nem um bom matemático.

Para detectar uma colisão simples, o ideal é usar cálculos e algoritmos que usem poucos ciclos de CPU. É bem difícil saber o quanto um cálculo usa de CPU. Mas podemos deduzir a complexidade dele pela quantidade de linhas de códigos e quantidade de loops usados.

Uma das minhas idéias iniciais para detectar colisão deixou o jogo com uns 5 quadros de animação por segundo. Enquanto as outras duas mantinham a velocidade de 50. Aí podemos ver que não daria certo usá-la

Mas porque ficou tão pesado? Porque o que eu fazia era comparar pixel por pixel a área utilizada por cada um dos sprites que eu estava testando a colisão. Quando eu vi a degradação da performance, logo busquei outra alternativa, bem mais leve.

Vamos a elas:

Mas para fins didáticos, vou mostrar minha idéia dos 5 FPS:

Comparando colisão entre sprite1 com sprite2:

1 - gerar lista com todos os pixels do sprite1

2 - gerar lista com todos os pixels do sprite2

3 - comparar cada pixel com sprite1 com cada pixel do sprite2

Este método é bastante lento, mas 100% confiável. O problema é que se um sprite com 50x50 pixels for comparado com outro sprite 50x50, estaremos comparando 2500 pixels contra outros 2500. Isso tudo 50 vezes por segundo.

O método mais simples e igualmente preciso que eu usei no jogo foi este:

1 - Verificação Horizontal (Eixo X):

1.1 - Subtrair a distância (sempre em pixels) da extremidade da direita do sprite mais à direita com a extremidade esquerda do sprite mais à esquerda;

1.2 - Somar a largura do sprite1 com a largura do sprite2;

1.3 - se a distância for menor ou igual à soma das larguras, realizar a verificação Vertical.

2 - Verificação Vertical (Eixo Y):

2.1 - Subtrair a distância (sempre em pixels) do topo do sprite mais acima com o fundo do sprite mais abaixo;

2.2 - Somar a altura do sprite1 com a altura do sprite2;

2.3 - se a distância for menor ou igual à soma das alturas, a colisão foi confirmada.

No passo 1.3, vejam que há condição para continuar. Se uma colisão em uma das dimensões não tiver sido detectada, não há necessidade de testar na outra dimensão.

Colidir em uma dimensão parece coisa de doido, mas o que quero dizer é o seguinte:

Na figura acima, houve uma colisão no eixo Y, mas não no eixo X. Portanto, para um jogo 2D, não houve colisão. Veja que os dois quadrados ocupam as mesmas posições referentes a altura.

Já nesta figura acima, houve uma colisão no eixo X, mas não no eixo Y.

E aqui, finalmente ocorreu uma colisão nos dois eixos.

Segue o código abaixo.

Vocês devem ter visto que existe uma classe chamada Sprite. Esta classe é uma implementação minha para facilitar as coisas. Uma das facilidades é poder retornar o X/Y de cada um dos vértices do pictureBox, obtido através do Location e do Size. A implementação da classe Sprite segue abaixo:

Parte 6 - Colisão de Borda