Se Platão defende que a narrativa é a imitação da realidade e videogames são um mídia através da qual podemos retratá-las, temos de ter ferramentas para imitar fenômenos naturais. Entretanto este não é um post sobre física avançada. Vamos falar de sólidos.

Te garanto que o problema de detectar quando um objeto colidiu com outro e como proceder a partir daí é central a maior parte dos seus jogos favoritos ☗. Parece bobo, mas o número de coisas que pode dar errado planejando como lidar com isso é assustador.

Mas não se assuste. Para ajudar a tratar todo esse terror, nós vamos contar com a ajuda do nosso mais novo mascote: digam olá para o Coliditto.

Impenetrabilidade em Jogos

Dois parágrafos e já vamos falar de metafísica: Impenetrabilidade é uma propriedade da matéria que diz que dois corpos não podem ocupar o mesmo lugar no mesmo instante. Essa propriedade é o que faz com que coisas que tentem fazê-lo colidam entre si. Ainda que pareça um detalhe técnico, é um conceito tão natural para nós que quando um jogo faz isso muito mal, a quebra de expectativa em relação à realidade que conhecemos é tão grande que temos dificuldade de manter a imersão.

Quantas estrelas merece essa princesa?

Para simular impenetrabilidade de maneira simples, em geral jogos delimitam uma área ao redor do corpo sólido que chamaremos de colisor. Sem entrar em detalhes, o processo funciona de maneira simples, em duas fases:

1. Detecção de colisões: o jogo verifica se dois objetos compartilham pelo menos um ponto de intersecção. Se sim, eles estão colidindo, se não, não estão.
2. Tratamento de colisões: aqui rola o vulgo “Ok, bateu. E agora?”. O jogo precisa decidir o que fazer com os objetos que estão colidindo. Podemos, por exemplo voltar um dos objetos até o último instante onde eles não estavam mais colidindo, ou arrastar um dos objetos pra fora do outro até que eles não estejam mais colidindo (em geral a bola, porque acho difícil a parede ceder passagem).

Tudo o Que Pode Dar Errado Quando Você Bate em Alguma Coisa e Por quê

O processo é simples, mas muito pode dar errado. Tenho certeza que todos já têm exemplos em mente de vezes em que viram algum problema com colisões em jogos. A seguir vamos explorar alguns exemplos e especular o que pode levar eles a acontecerem. Vale notar que a bibliografia sobre como essas coisas são realmente implementadas não é muito disponível, e uma grande parte das possibilidades que vamos discutir aqui são especulativas, mas não deixam de ser um exercício interessante para entendermos como as coisas funcionam.

Super Mario 64: GOTTA GO FAST

A primeira vez que eu vi isso, meu palpite de como isso poderia acontecer foi em relação a fase de detecção de colisões. A cada instante, que em geral representa 1/30 de um segundo ou 1/60 de um segundo em jogos modernos☗, o jogo vai tentar movimentar Mario um pouquinho, e verificar se ele colide com algo. Há duas grandes maneiras de pensar como isso funcionaria. A primeira é chamada de colisão em espaço discreto:

Neste caso, botamos Mario diretamente na posição pra qual ele tem que ir naquela fração de tempo, e então passamos pra etapa de detecção de colisões. Se ele estiver colidindo com a parede, o tratamento da colisão vai se encarregar de jogar o personagem pra fora dela. Parece tosco (e na real é um pouco), mas se algumas propriedades forem respeitadas, o modelo funciona. Se a distância máxima que o personagem puder percorrer em um frame for menor ou igual ao diâmetro do seu colisor, podemos garantir que não tem como ele ultrapassar aquela parede nunca. Ou seja: se o tamanho do colisor e a velocidade máxima do personagem forem fatores compatíveis, tá tudo suave.

A engine de Super Mario 64 tem colisores do tamanho certo limita a velocidade máxima de Mario, então em tese eles estariam seguros. Mas esse limite de velocidade só vale para velocidade POSITIVA. O vídeo acima usa um bug do jogo usando pulos que faz com que Mario se desloque extremamente rápido para trás. O que acontece? Poof. Vai direto através da parede.

A segunda grande maneira de abordar as colisões arrumaria esse problema. Ela se chama detecção em espaço contínuo: antes de mover o personagem, o jogo verifica se há alguma colisão possível entre a posição atual do personagem e a posição pra qual ele quer ir. Se houver uma colisão, ele passa a informação de em que ponto isso aconteceu para a fase de tratamento.

No tratamento ele pega a posição onde houve a colisão, e então move o personagem pra lá. Não importa quão rápido Mario se deslocasse, a colisão nunca seria ignorada. O curioso é que supostamente há um artigo publicado que explica um algoritmo que teria sido usado na engine de Super Mario 64, e ele já sugere o método contínuo. Especulamos que ele não foi implementado exatamente como é dito no artigo, o que gera o comportamento que vimos. Mas talvez esse comportamento ocorra por algum erro na fase de tratamento da colisão que acabe posicionando Mario do outro lado da parede por sua velocidade ser negativa. Fica o questionamento.

The Legend of Zelda: Ângulos Agudos☗

Ocarina of time começou seu desenvolvimento na mesma engine de Super Mario 64, mas segundo Miyamoto a engine foi muito alterada. Se olharmos no mesmo artigo que descreve o algoritmo de colisões de Super Mario 64, eles descrevem um método que faz com que o personagem conserve seu movimento rente a uma parede quando ele colide com ela, como se ele estivesse deslizando rente a ela.

Quando isso acontece entre 2 paredes que formam um ângulo agudo, fica difícil determinar a posição que o personagem deve assumir após a colisão, porque cada uma das paredes vai tentar empurrar o personagem em uma direção perpendicular a elas, preservando a velocidade que ele tinha em outras direções.

É interessante notar que há vários jeitos de ultrapassar paredes em Zelda, mas a grande maioria dele envolve paredes com ângulos agudos e alguma estratégia para ganhar velocidade suficiente para ser passado através delas (que nem vimos no exemplo de Mario).

Neste caso em específico, também é possível que o jogo só trate a colisão em relação a uma parede, ignorando a outra, o que causa o efeito de que link é jogado apenas através da parede da direita. Em geral jogos possuem um buffer de tamanho físico que determinas quantas colisões simultâneas podem ser detectadas. Se o número de colisões ultrapassar esse limite, elas são ignoradas. Talvez não seja o caso em Zelda pois a estrutura de dados que guarda informação de colisões permite que mais de um polígono seja listado como alvo de uma colisão.

Skyrim e Buffer de Foda-se

Tendo explicado o fato de que os jogos processam colisões contra um número finito de objetos, adivinha quem está verificando só a colisão contra o prato?

Curiosamente este problema não ocorre quando se tenta colocar o prato contra uma parede côncava. Especulamos que isso se deve ao fato de que os objetos não são mais co-planares. O espaço que fica entre o prato e a parede pode ser suficiente para que o jogo passe a detectar a colisão entre o personagem e a parede.

Spooky’s Jump Scare Mansion: PARA TUDO Edition

Pra quem não conhece: é um jogo indie de horror baseado um pouco em SCP☗, onde você está preso em uma mansão onde por mil salas você vai ser perseguido por monstros que começam fofinhos e inocentes e terminam como bestas sanguinárias e incansáveis.

O jogo fica tenso rápido, e um dos aspectos que colabora pra isso é o seguinte: lembra que comentamos que em Super Mario 64 quando você se move rente a uma parede, ele só não deixa você entrar na parede, mas desliza você rente dela, preservando parte do seu movimento? Aqui os designers escolheram outra estratégia: o ângulo pelo qual você consegue passar deslizando por uma parede é beeeem menos tolerante:

Na primeira parte, o personagem bate no canto da quina da parede. Ele não deixa você deslizar por ela, ele PARA completamente o movimento. Você tem que ir pra trás e dar a volta naquela esquina, ou virar bastante a câmera até a ponta do cubo deixar de bater na parede. Agora: imagina você ter que gerenciar isso enquanto tem um bicho maluco querendo seu cérebro.

Logo após, o personagem tenta andar pra direita enquanto está encostado em uma parede. Ele não consegue deslizar, então começa a andar na diagonal (pra trás e pra direita). O movimento “serrilhado” resultante acontece porque quando o personagem está colado na parede, ele está tentando ir pra direita e pra trás. Pra direita ele não pode se mover pois está colidindo, mas pra trás pode. Então ele vai pra trás, e aumenta a distância dele com a parede. Quando ele vai pra direita de novo, ele bate de novo, e interrompe o movimento. Isso se repete rapidamente, mas é tudo derivado do aspecto de que o movimento é interrompido.

É um caso onde a resposta a colisões não é fluida ou 100% agradável para o jogador, mas isso colabora muito para manter o clima estressante e aterrorizante do jogo. Às vezes uma escolha de design que não é agradável ao jogador pode funcionar caso colabore para o clima que o jogo está tentando criar.

Série Souls: Hitbox Porn (GONE SEXUAL)

Os jogos da série Souls são conhecidos por terem um combate com hitboxes tão precisas que geram narrativas emergentes de combates que o jogador vai querer documentar para mostrar pros netos, de tão épico que é o esquema:

As hitboxes são animadas, o que significa que elas mudam de tamanho, orientação e posição durante as animações do personagem. No vídeo, dá pra ver que durante a animação de ataque do personagem, ele abaixa um pouco. Esse pouco é suficiente para ele desviar por milímetros do ataque inimigo. É realmente um sistema primoroso.

Quando se trata de colisões com o terreno, os jogos da série são menos cuidadosos. Especialmente porque eles focam muito mais em te dar uma experiência de combate dinâmico, vivo e excitante do que simplesmente simular caminhadas com perfeição. No final das contas o contraste entre o sistema de colisões em combate e o de terreno é HILÁRIO:

Lembram que as hitboxes mudam de tamanho durante as animações? Quando o Fire Demon nesse vídeo toma muito dano, ele faz algumas animações para mostrar ao jogador que ele está ficando desgastado. Elas também alteram o tamanho, orientação e posição de suas hitboxes. Entretanto, o inimigo continua tentando chegar até o jogador através de um espaço onde ele não cabe. Acontece que algumas dessas animações são suficientes para que ele consiga passar pelo menos por um pedaço da parede. No final do vídeo, quando ele ergue o corpo em uma das animações de quando ele toma muito dano, o centro dele ultrapassa o topo da parede, e aí o sistema de tratamento de colisões do jogo entende que ele estava dentro do teto e agora está ultrapassando o “chão”. Na etapa de tratamento da colisão, ele é atirado pro espaço que tem acima do teto.

Smash 4: Colisão Contínua Também Dá Pau

Em jogos com muitos elementos que se movimentam, colisões no método contínuo também têm seus problemas. Nesse caso, o Mr. Saturn está querendo ir para a esquerda, e a plataforma também. Durante as fases de detecção e tratamento de colisão do Mr. Saturn não tem nada impedindo ele de se mover naquela direção, então ele se move pra esquerda e começa a cair. No mesmo instante, a plataforma vai ter sua posição e tratamento alteradas também, e quando ela tenta se mover, o Mr. Saturn que estava caindo não pode mais cair. No próximo ciclo de atualizações, ele vai tentar se mover para a esquerda de novo, e esse conflito vai se repetir.

Colisões contínuas não lidam bem com muitos objetos que se movimentam dinamicamente. Como os objetos se movimentam um de cada vez, cada um com seu ciclo de detecção, tratamento e movimento, dependendo da ordem na qual os objetos são processados os resultados finais podem ser diferentes. Prever isso e tratar antes que aconteça é uma tarefa hercúlea. E calcular as colisões de todos primeiro e depois executar todos os movimentos pode gerar situações onde dois objetos têm uma intersecção. A partir do momento que isso acontece, se torna necessário usar a etapa de tratamento do método discreto e retirar os objetos de dentro da intersecção. Se quisermos levar em conta a velocidade e peso de cada um deles, começamos a entrar em simulação de física, e não mais colisão simples. E isso é outro papo.

Conclusões

Se você acha que entrar dentro de uma parede, ficar preso no teto, ser teletransportado para o outro lado do mapa são coisas exclusivas de jogos independentes, que foram feitos por meia dúzia de malucos, meu amigo: você está enganado. Como a gente viu, até os desenvolvedores de jogos triple A☗ estão sujeitos a isso. 

Eis uma citação do Brad Hines, funcionário da Eidos sobre detecção de colisões (fonte aqui):

Colisão em video-games é uma parte de um grande e complicado conjunto de sistemas. É criado por seres humanos que são capazes de cometer erros, ou apressar trabalho, ou ter coisas mais prioritárias para fazer. O desenvolvimento de jogos geralmente é baseado em um prazo apertado e infelizmente problemas menores podem ser deixados de lado.

É um problema que não tem uma só solução, e nenhuma delas é 100% perfeita. Passa a ser um problema de onde você pode fazer concessões no seu jogo. Tanto Dark Souls quanto Spooky’s House of Jumpscares usam algoritmos de colisão com terreno que não são ideais, mas são concessões que eles fazem porque esses problemas não ficam no caminho de como eles querem que você jogue. Esse tipo de escolha de design é arriscada, mas às vezes vale mais a pena ignorar um problema menor do que ficar martelando em cima de um ponto que não é tão importante pro seu jogo.

Claro que é importante conhecer as opções e escolher a que fizer mais sentido, mas todo mundo está sujeito a uns problemas com isso. Fica com o vídeo da Bianca Velloso pra te garantir que a treta é séria até em 2016: