quinta-feira, 13 de maio de 2010

Jogar, jogar...programar

Jogos. Sempre gostei deles. Gosto de jogar (e jogo) desde os 12 anos. O que me dá dez anos de experiência. A cerca de dois anos (desde que desenvolvo software profissionalmente) me interessei pela área de desenvolvimento de jogos. Como tudo começa do início, eu acabei aprendendo os princípios básicos dessa área tão interessante do desenvolvimento de software. Eu já desenvolví um jogo da velha em Delphi (eu sei, todo mundo já fez um), já fiz um jogo das bolhas no meu palm. Foi legal aproveitar o touch screen. Tentei desenvolver algo pro Ipod Touch (é, já tive um), mas a empresa da maçã e seu proprietarismo monárquico não me deixaram prosseguir. É possível criar algo em J2ME também. No futuro eu vou mostrar como, mas hoje, vamos nos ater aos princípios básicos.

Programação de jogos é algo extremamente complexo. Sem entender alguns conceitos básicos é impossível programar.
Primeiro conceito:
Sua tela é uma matriz. A tela do computador é constituída de uma série de pontos. Cada um desses pontos é localizada por um ponto XY, como num plano cartesiano. Então, para movermos um objeto na tela para frente ou para trás basta incrementar (aumentar) o valor de X desse objeto. Para fazê-lo voltar basta decrementar X. O mesmo  princípio vale para o Y.
Segundo conceito:
Orientação a Objetos. Esse modo de pensar é usado desde que mundo é mundo. Como este não é um artigo sobre OO, apenas tenham em mente que é necessário para desenvolver jogos.
Terceiro conceito:
Sprite. Não. Não é o refrigerante! Sprites são pequenas animações repetidas que são acionadas quando o usuário envia um comando. Por exemplo, quando você clica no mouse e a arma que você está segurando dá um disparo (nós não estamos falando de jogos 3d, ok. É só um exemplo). A animação que faz a arma emitir uma luz na ponta é um sprite. Esta animação é sempre a mesma e sempre vai ser disparada pelo mesmo evento. Isso é um sprite.
Quarto conceito:
Double Buffering. Essa técnica é antiga e praticamente obrigatória. Na maioria das vezes a própria linguagem já implementa automaticamente. Double buffering resolve um problema de atualização da tela. Toda vez que um objeto mudar de posição na tela é necessário redesenhar tudo com as novas posições. Imagine que sua tela é como um quadro de pintura e que os objetos são pintados sobre este quadro. Porém, ao repintar o quadro para atualizar a posição de um objeto, você verá um pequeno delay dessa atualização. É pequeno, mas quando se junta tudo fica extremamente incômodo. Para resolver este problema, basta colocar um quadro sobre o quadro. Quando for atualizar a tela, você desenhará sobre este segundo quadro. Quando terminar de atualizar o quadro com todas as novas posições dos objetos, você pinta ele sobre o quadro principal. Isso acaba com o delay de atualização da tela.
Quinto conceito:
Algoritmo de detecção de colisões. Tá bom. Esse é difícil. Honestamente, não conseguí implementar nenhum que seja 100% eficiente. Existem diversas técnicas diferenciadas e a que eu mais gostei foi a quadtree. Ela consiste em utilizar a estrutura de dados árvore para mapear a tela. Cada parte da tela é representada por um dos nós da árvore e esses nós possuem mais quatro nós e assim por diante. Com uso dessa técnica é possível reduzir drásticamente a quantidade de cálculos necessária para detectar que um objeto colidiu com outro. Isso porque a verificação ficaria restrita ao setor (nó da árvore) em que os objetos estão. Tem um artigo na sharpgames de um cara que implementou o mesmo: http://www.sharpgames.net/Artigos/Artigo/tabid/58/selectmoduleid/376/ArticleID/1603/reftab/54/Default.aspx.

Ok. Com isso aí já dá pra fazer um joguinho 2D básico (quase um Mário Bros!!!). Em outro post eu posto um exemplo usando Java.

Nenhum comentário:

Postar um comentário