Eu já gosto do tema “Zumbis” e achei esse pequeno (e viciante) jogo em que você encarna um mercenário que com sua equipe deve livrar uma pequena cidade de uma ameaça zumbi. Não se engane, embora clichê (aliás o jogo dos Simpsons para PS3 é muito legal em indicar clichês de vídeo game,) o jogo é viciante !

Jogos em flash não são exatamente difíceis de fazer, mas é muito interessante de jogar. Eu queria colocar o jogo mesmo aqui no site, pelo menos o link, mas a largura do jogo (700 pixels) estoura a dimensão atual do site, “ah mas porque você não configurou o flash?” na verdade eu tentei, mas aí o jogo fica com as laterais cortadas.

O que acontece, que aliás é muito comum, é que o jogo é projetado para ter uma certa dimensão e não é muito simples fazer o jogo todo com componentes que possam ser redimensionados dinamicamente, não que seja impossível, mas é um tanto trabalhoso.

Nesta foto eu tinha acabado de ganhar uma partida, mas como não foi sem erros, a dupla adversária chegou a marcar pontos, então eu perdi 22 pontos de habilidade baixando de 2183 para 2161. Outra coisa engraçada é ver o gráfico de habilidade fora da area do desenho

Explico, sem ter outra forma de me dar pontos o video-game passa a me graduar somente quando eu ganho a partida de zero, ou seja, se eu não errar nada. Tudo bem que isso é uma forma de tratar o problema, mas fica bem chato. Eu gostaria de experimentar agora o virtua tennis para wii, li que ele utiliza o acessório wii motion plus e permite um jogo muito mais realista, o triste é pagar o preço do jogo aqui no Brasil né? Estou tentando que alguém traga para mim de fora, bom também aceito doações né ?

É 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.

Em algumas experiências que fiz com diferentes frameworks, um me chamou muito a atenção. O Box2D é uma biblioteca que permite realizar diversas atividades relacionadas ao cálculo de características de física nos jogos, coisas como gravidade, colisão, atrito, velocidade, aceleração entre outros. É muito poderoso e tem implementação em várias linguagens diferentes, tem para linux e tem para windows.

Experimentei o Box2D quando participei no LudumDare 15 e não foi exatamente um passeio no parque principalmente porque a documentação do Love2D não estava muito legal, tive que olhar exemplos em outras linguagens e deduzir como fazer funcionar em Love2D. Uma das principais coisas a dominar é que o Box2D foi criado para trabalhar com “micro mundos” isso quer dizer que os cálculos são feitos com números pequenos, dessa forma você precisa usar um fator de multiplicação entre o mundo de física e o gráfico que representa esse mundo, eu sei que isso não ficou muito claro e em outro post eu vou colocar um exemplo de código.

O objetivo aqui é falar de como uma ideia simples pode ser implementada e transformada em magia (com o Box2D por trás disso.) Depois de usar essa biblioteca fui procurar outras implementações para ver como usar e onde poderia usar, acabei esbarrando em um jogo que usa essa biblioteca e que ganhou um prêmio no concurso no qual foi inscrito.

O Crayon Physics Deluxe é um jogo de quebra-cabeças onde o usuário tem o objetivo de acertar a estrelinha da tela com uma bola que também aparece na tela já de início. Bastante simples, o detalhe (que brilha como mágica) é que o usuário DESENHA os componentes com os quais vai trabalhar e a física do mundo atua sobre esses componentes desenhados (que nem existiam!!!) Parece difícil, mas quem já programou usando o Box2D sabe que não é nada do outro mundo, já o efeito visual que isso causa no usuário…

Crayon Physics Deluxe from Petri Purho on Vimeo.

Outro detalhe muito legal é que os desenhos são todos feitos com um traço que parece giz de cera e sobre uma foto de papel dobrado, dá uma impressão muito real ao jogo.

Grande parte da discussão se tratava em não ser aceitável para o usuário ter que colocar o controle sobre uma mesa e marcar aquele como o ponto de origem, para a programação esta simples tarefa facilitaria muito a vida porque poderí­amos tomar aquele ponto como referência. Pois bem, com o lançamento do Motion Plus que inclusive vem junto quando compramos o jogo Wii Sports Resort, podemos tornar o wiimote muito mais sensí­vel e executar manobras que não podiam ser captadas antes.

Porém este novo acessório precisa ser calibrado toda vez que você entra no jogo, alí­as as vezes (muitas vezes) durante o próprio jogo, por ser muito mais sensí­vel. E como é o processo de calibração ? Por favor, apoie o seu controle sobre uma superfí­cie lisa e plana…