Muito bem, amigos, finalmente consegui retomar esta série com algo interessante. Visto que "Pong 4 Linux" não é nem de longe "interessante", e o nosso próximo projeto que já está "estourando a bolsa" – Sendo este o NABA –, é que eu comecei, de maneira independente, a criar uma engine para criação de qualquer tipo de jogo com menos passos do que normalmente necessário. O objetivo é criar um "Game-Maker-like" para Linux, visto que essa coisa não existe. Mesmo que sem interface...

Então eu comecei a pensar numa coisa... colisões.

Veja bem, todo jogo é baseado em colisões. Bom, nem todo. Alguns jogos podem ser abstraídos em função de outro tipo de coisa que não colisões. Mas esses são casos especiais. Em primeira instância, o que temos é um monte de objetos que interagem uns com os outros. E aí que mora o problema.

Dependendo de sua estrutura, um jogo "complexo" – em contraposição a jogos "simples" como Pong, Breakout e Tetris, que podem ser mais facilmente otimizados – é composto de muitos e muitos objetos. Pegue Super Mario Bros, por exemplo. Mario, cada inimigo, cada bloco quebrável, cada bola de fogo, é um objeto de jogo. E daí vê-se que existem algumas dezenas de objetos interagindo por fase. E agora é que entra a parte computacional do raciocínio.

Cada objeto verifica se colide com outro e realiza as instruções programadas para aquela colisão em especial. E isto se repete para cada outro objeto do jogo. E cada objeto em particular realiza essa rotina de verificação de colisões. Só em termos de comparações, isto dá n(n+1) instruções por ciclo. Para um jogo com algumas dezenas de objetos, isto dá algumas centenas de instruções. E se você não entende muito de computação, eu digo: é muito. É demais. E, em um jogo, desempenho é tudo.

Então a questão é: como fazer um sistema de colisões de uso geral? Até o momento, a melhor otimização que consegui foi realizar apenas metade das verificações de colisão(ou seja: a colisão de A com B é verificada, mas não de B com A), visto que a colisão é, por assim dizer, uma operação comutativa. Ainda assim pode ser muito.

Assim, aceitamos sugestões. No mais, apenas um exercício mental para programadores. Afinal, o que é mais divertido do que pensar em abstrações algorítmicas? ;)