Depois de algum tempo, termino esta série. A idéia desde o início era simplesmente explicar o básico sobre desenvolvimento de games conforme eu fosse aprendendo. Desde o primeiro post, o jogo WinForms Lander já estava praticamente completo. E claro, como nem todos gostam de ler posts técnicos, fui alternando os posts com posts padrão deste blog. Por isso a série demorou para acabar. Mesmo assim, recomendo muitíssimo a todos a leitura dos posts anteriores, pois eu tentei ser bastante didático e teórico, não se prendendo somente em códigos. Acredito que os textos tenham ficados bem agradáveis e com conteúdo interessante. Mesmo se você não quer desenvolver.

Leiam o restante para acessar os downloads:

Ao longo do desenvolvimento, fui tomando algumas decisões de design e alterando coisas. A principal alteração foi o uso de código 100% nativo para leitura de teclas. Agora não é mais necessário usar aquela dll do XNA para isso. O código eu achei na internet e mantive intacto, junto com o comentário que identifica o autor.

Outra coisa foi o uso de código nativo para tocar arquivos de áudio multimídia. Também peguei da internet. A biblioteca original do Windows Forms/.Net só permitia tocar um som por vez, e ainda somente .WAV. Agora o game toca mp3.

Algo que descobri desenvolvendo o game é que a parte audiovisual é um grande limitador para quem desenvolve sozinho. Fazer um game sem uma equipe multi-talentosa requer um criador multi-talentoso. Criar gráficos 2D estáticos é fácil. Mas criar sons, músicas, animações, backgrounds sem copiar tudo de outras fontes é extremamente difícil para um simples programador.

E aí vem o problema. Encontrar bons efeitos sonoros é muito mais difícil que encontrar músicas. Acredite.

Um dos grandes problemas para desenvolver este jogo foi tentar incluir cenários. O Windows Forms aceita inserir imagens de background, mas qualquer animação fica meio quebrada. A detecção de transparência não é muito boa. Por isso, e também por falta de habilidades de minha parte, não foi possível colocar backgrounds, muito menos obstáculos nas fases, como montanhas, relevos e etc.

Isso levou a algumas idéias interessantes para aumentar o desafio de pousar as naves. Eu fiz com que em cada fase a plataforma se movesse de variadas velocidades e direções para dificultar um pouco e diferenciar as áreas mais avançadas. Algumas áreas possuem ventos. Outra coisa que inseri nas últimas fases foram asteróides que ficam caindo em velocidades e direções variadas, para atrapalhar um pouco.

No geral, acho que o game ficou bem completo.

Tentei neste game incluir um pouco das coisas que sinto falta em alguns games, como fases variadas, prêmios e incentivos para continuar a jogar. Tudo isso na escala do jogo, claro.

Bom, depois de tudo isso, vamos aos downloads:

Aqui tem os fontes.

Para codificar, adotei por padrão o idioma inglês. Acho mais fácil em inglês porque assim evitamos estrangeirismos, acentuações ou traduções grosseiras geralmente vistas no código em “português”. Se for codificar em português e usar “GetValor” para nomear alguma função, então que se adote o inglês de uma vez! Ou usa “PegaValor”. Os comentários estão todos em português, no entanto.

Aqui tem o executável.

Aqui tem o executável sem o áudio, para quem tiver problemas.

Para rodar o game, é necessário ter o .Net 2.0 instalado. Talvez precise de alguma outra biblioteca, mas não consegui testar em uma grande variedade de PCs para me certificar se está tudo ok. Qualquer problema, deixe um comentário.

Edit:

PROBLEMA – a biblioteca de audio que usei pode não funcionar corretamente em alguns sistemas (foi o caso do Kazuma). Como a biblioteca não é minha, não sei porque não funciona. Vou investigar. Enquanto isso, estou disponibilizando uma versão sem áudio do game.

VISUAL – Como utilizei controles visuais usados em formulários de sistemas, como barras, botões, painéis e etc., as imagens ficarão melhores se o jogo rodar no modo visual clássico, e não com o tema do XP (ou mesmo Aero). Cliquem com o botão direito no WinFormsLander.exe e em Propriedades >> Compatibilidade, marquem “Desabilitar temas visuais”.

Parte 1 – Início

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

Como aplicar física em jogos?
1 - Usando uma boa engine que já faça isso;
2 - Usando boas bibliotecas que façam isso;
3 - Manifestando um pouco do Newton que há dentro de nós;

Como a idéia toda desta série é entender como tudo funciona, e não simplesmente criar um jogo o mais rápido possível, ficaremos com a terceira opção. Apesar de eu gostar de física, nunca estudei muito tal disciplina, e hoje sinto bastante dificuldade com vários cálculos básicos. Graças ao jogo em si, eu consegui redescobrir muitas coisas, pois na prática é mais fácil de entender um conceito.

Vamos:

A Física, entendida por muitos estudantes como a abreviação da disciplina "Educação Física", não é chutar uma bola e marcar um gol, e sim calcular sua tragetória, peso, velocidade, aceleração e etc.

Para quem quer criar jogos de RPG, ignorem tudo isso. Para os demais, vamos analisar algumas coisas:

Num fluxo de jogo, não basta aplicar uma fórmula para deslocar um objeto para outro lugar. É preciso MOVER o objeto um pouco a cada update.

Como o fluxo é contínuo, você não deve prever onde os objetos estarão, e sim mover os objetos na direção que a fórmula deve prever. Complicado?

Quando aplicamos uma fórmula para descobrir a aceleração ou velocidade de um corpo, o que obtemos é o valor em distância/tempo (km/h, m/s, mph, etc...). Se temos a velocidade e multiplicarmos pelo tempo, obteremos a posição onde o corpo estará.

Mas para um sprite se mover, temos que reposicioná-lo a cada Update. Como num jogo 2D comum temos pixels, e aqui temos nosso Update() disparado por Timer.Tick() a cada 20 milisegundos, nossa velocidade é medida em pixels por tick.

Ou seja, se um sprite se desloca com uma velocidade de 1 p/t (pixel por tick), e um tick é disparado a cada 20 milisegundos (resultando em 50 ticks por segundos), temos a velocidade de 50 pixels por segundo.

Numa tela de jogo de 640 pixels de largura, o sprite demoraria 13 segundos para atravessá-la completamente.

Definindo um pouco as coisas:

Velocidade: é a taxa mudança de posição de um corpo ao longo do tempo. Se a cada tick temos a mudança de posição em 1 pixel, nossa velocidade é 1 p/t (não existe essa medida, e nem adianta sugerir à SI).

Aceleração: é a taxa de aumento de velocidade num determinado período de tempo. Se no primeiro tick temos 1 p/t, e no próximo temos 2 p/t, no terceiro estaremos com a velocidade acumulada do primeiro somado do segundo (1 + 2).

A cada tick o sprite pulará mais pixels de uma vez:

Ticks:    |
Pixels:   +

|+|++|+++|++++|+++++|++++++|

Como representar isso?

Simples. É só criarmos uma variável para acumular a velocidade e somá-la aos pixels que representam a localização dos sprites.

No exemplo da bola na parte 3, nós movíamos a bola em um pixel a cada tick quando o jogador mantinha uma seta pressionda. Agora vamos acrescentando unidades em uma variável e transferiremos o valor total dela no Location do sprite:

o que estamos fazendo acima é:

1 - Criar uma variável para armazenar velocidade;
2 - Adicionar ou subtrair unidades a ela dependendo da direção esquerda/direita (velocidade na direção oposta é negativa)
3 - reposicionar o pictureBox acrescentando a velocidade à sua posição no eixo X atual;

Execute e veja como para os lados a bola possui aceleração, velocidade e inércia. Enquanto para cima e para baixo ainda se move do jeito antigo.

Aqui vai o código completo da tela: link

Parte 5 - Colisão Simples

Para começarmos, será necessário criar um novo projeto do tipo Windows Application no Visual Studio 2008. Ao criar um novo projeto, cria-se uma Solution que abriga este projeto.

Uma solução recém criada já apresenta um formulário chamado Form1. Podemos utilizar ele mesmo.

Com o XNA 3.1 devidamente instalado, vamos importar a DLL Microsoft.XNA.Framework e Microsoft.XNA.Framework.Game.

Para isso, clique com o botão direito na pasta References no menu Solution Explorer e selecione Add Reference. Aguarde a janela aparecer (demora!) e na aba .Net, selecione as DLLs Microsoft.XNA.Framework e Microsoft.XNA.Framework.Game nas versões 3.1.0.0.

Abra o ToolBox (CTRL + W + X) e, na entrada All Windows Forms, procure e arraste para o formulário o controle chamado PictureBox e outro chamado Timer.

Selecione o PictureBox e na aba Properties (F4), mude a propriedade Size para 32;32. Na propriedade BackgroundImage, clique e em Local Resource, navegue nos diretórios e selecione uma imagem qualquer. Sugiro salvar e usar esta aqui:

Agora vamos mexer no Timer. Selecione lá embaixo o timer1, que foi criado ao arrastar o Timer. Em Properties (F4), mude o Interval para 20 (50Hz). Mude também o Enabled para true;

Agora vamos implementar o evento Timer.Tick. Ainda em Properties, no topo da aba existe uma figurinha em forma de raio. Clique nela. Aqui temos os eventos disponíveis para o Timer. O único disponível é o Tick. Clique duas vezes na célula vazia e o Visual Studio vai criar o evento e a função associada ao evento (event handler), chamada timer1_Tick().

Todo o código fica neste arquivo.

Vamos escrever algumas coisas por aqui. Primeiramente, vamos criar um objeto do tipo KeyboardState. Logo acima da linha public Form1(), escreva:

Agora, dentro do bloco timer1_Tick(), escreva:

O que estou fazendo acima é a cada 20 milisegundos:

1 - Capturar o estado do teclado (teclas pressionadas);

2 - Verificar se a tecla pressionda é a Seta Para Cima;

2.1 - Se sim, a localização do pictureBox1 muda para um novo ponto cartesiano, onde o eixo X mantém o mesmo  valor, e o Y é decrescido de um pixel.

O problema desses controles é que a posição é definida por um objeto Point que une o X e o Y. Então eu não posso simplesmente decrementar diretamente o Y,  e sim recriar o Point, repassando o X e o Y do jeito que eu quero.

O interessante é que quanto mais para cima, menor é o Y. Ou seja, o ponto X=0 e Y=0 é o canto superior esquerdo do formulário. Isso vale para qualquer aplicação baseada em pixels na tela. Até o paint.

Agora vamos rodar o programa. Pressione F5 para compilar e rodar. Se tudo deu certo, o formulario e a figura aparecerão na tela. E ainda se moverá para cima enquanto a tecla Seta Para Cima estiver pressionada.

Podemos fechar a janela e continuar o programa.

Ainda dentro do timer1_Tick(), vamos aplicar todas as direções.

Basta escrever o restante:

Agora rode novamente e experimente mover a bola para todas as direções.

Por enquanto é isso. No proximo post, vamos aplicar aceleração e outras coisas a mais.

Parte 4 - Física

Qualquer jogo possui uma estrutura genérica que geralmente segue o mesmo padrão. Aqui, o principal é mostrar o básico, e sem utilizar ferramentas que escondem alguns dos passos básicos do fluxo.

Como eu havia falado, o Windows Forms atualiza as figuras na tela automaticamente quando detecta uma mudança, e isso é bem difícil de controlar manualmente. Então, a parte de fazer as imagens ser renderizadas fica oculta para nós.

Abaixo está a figura com o fluxo básico do WinForms Lander. Vejam:

Como podem ver, não é nada muito complicado. Dos 3 blocos, o mais importante é o Update. Nele todas as coisas que fazem a partida funcionar são continuamente executadas num loop infinito. Bom, só não é infinito porque se o jogador vencer ou perder, o loop se quebra e o jogo segue para o terceiro bloco.

No caso do WinForms Lander, e muito povavelmente para qualquer engine, o update é disparado automaticamente. Geralmente é utilizado um temporizador (timer para os íntimos) que dispara uma função a cada X milisegundos. Em Windows Forms, eu utilizo o controle Timer. No evento Timer.Tick eu chamo a minha função Update().

O padrão para os jogos é rodar a 60 quadros por segundo, e isso conta também os updates, e não somente a atualização dos gráficos. Na verdade, como os videogames são feitos para ligar na TV, e a TV atualiza as imagens 60 vezes por segundo, o video dos consoles gera e envia imagens nesta taxa também. E como o processo de update e geração de imagens são síncronas, o update acaba rodando nesta velocidade.

Muito provavelmente, até os jogos de PC com taxa de quadros variável deve rodar seus updates 60 vezes por segundo. Ou seja, mesmo que o jogo esteja exibindo 20 frames por segundo, a captura de teclas, detecção de colisão, movimentos e toda a lógica do jogo está executando a cada 16,66 milisegundos (60Hz).  Isso se deve ao fato dos jogos modernos serem assíncronos. Ou seja, a geração das imagens não bate com a atualização delas, nem com a lógica de jogo. Isso quer dizer que é possível jogar Quake 3 com a lógica rodando a 60Hz, taxa de atualização do monitor à 85Hz, e 70 FPS. Num console, principalmente os antigos, é tudo síncrono. Acredito que nos consoles antigos, disparar o update seja uma implementação de hardware, com o uso de algum temporizador baseado num chip.

Mas isso é só suposição. Imagino que seja assim porque ao usar um jogo NTSC (60Hz) num console PAL (50Hz), o jogo roda mais lento. O inverso também ocorre.

Usando o Timer do Windows Forms, é possível informar o intervalo de tempo em que o evento Timer.Tick será disparado. Com isso, podemos fazer com que a lógica do jogo seja executada no tempo que quiser. E o melhor é que o intervalo pode ser alterado a qualquer momento. O legal é que diminuindo o intervalo, todo o jogo se acelera. Não sei se é possível alterar o intervalo em qualquer ferramenta.

Por enquanto é isso.

Parte 3 - Lendo Teclas

De todos os colaboradores da Cubagames, eu sou o menos familiarizado com desenvolvimento de jogos. Não tenho muita familiaridade nem com Web, que geralmente possui ferramentas muito boas para implementar um jogo, como é o caso do Flash.

Mas tenho bastante familiaridade com programação de sistemas e um pouco de conceito sobre criação de jogos. A plataforma de desenvolvimento que possuo mais experiência é Windows Forms, e a linguagem que mais domino é o C#. Há alguns anos venho pensando (filosofando) como os jogos antigos de 8 e 16 bits eram criados. Hoje temos muitas ferramentas visuais, frameworks, engines, todos equipados com temporizadores automáticos, eventos, gerenciamento de memória, threads e o escambal. Com isso, criar um jogo pode ser bem rápido, mas talvez não tão didático.

Acompanhem-me:

Aventurar-se numa ferramenta dessas pode ser bastante confuso. Até eu tive dificuldades de compreender o funcionamento do XNA. E olha que ele usa C# e o Visual Studio. É claro que agora, fazendo quase tudo no braço usando Forms, já consigo entender como o XNA funciona. É por isso que quero compartilhar este conhecimento aqui. Claro que "no braço" é um termo relativo, pois com C# e o Visual Studio muita coisa já vem pronta. Só que nada vem pronto para ser utilizado em jogos. Comparando com engines como a Unity, ou ferramentas como o Flash, C# e WindowsForms é bem cru. Se eu tivesse paciência para aprender C++, com certeza usaria ele aqui.

Por um lado, ferramentas completas são úteis e muito produtivas, mas para quem está interessado em conceitos, isso pode atrapalhar mais no aprendizado do que ensinar.

Muito antes de bolar meu próprio MMO para concorrer com WoW, eu quero entender como tratar uma colisão "no muque". Ou ainda, como trabalhar os updates por segundo de jogos mais rústicos, como os antigões. Essas novas engines mascaram tudo isso. (Recomendo ler um texto muito bom do Rômulo sobre isso: Design Inchado)

Então, por causa dessa minha curiosidade e também falta de compromisso para criar um jogo propriamente dito, comecei a fuçar um pouco no Windows Forms com C#, usando a ferramenta Visual Studio 2008. Aqui eu me sinto em casa. Porém, O WindowsForms já é todo otimizado e "fechado" para uso em programas com telas estáticas, com botões, campos de texto, barras, grids etc. Traduzindo, Windows Forms não foi feito para criar jogos. Então pensei: "Perfeito!".

O problema do Windows Forms é que o programa fica esperando o usuário interagir com as telas, pronto para capturar teclas pressionadas e cliques de mouse. Num jogo, o que ocorre é o contrário. Ele funciona continuamente, mesmo sem a intervenção do jogador. Ou seja, se você largar o controle por um tempo, morre.

Para poder quebrar essa primeira e talvez a única barreira que o WindowsForms oferece ao criar jogos, eu tive que usar uma biblioteca em que eu determinasse quando pegar as teclas pressionadas pelo jogador e aplicar a lógica de jogo. Ou seja, o programa não ficaria esperando as teclas serem pressionadas para disparar os eventos.

Comecei a procurar por uma biblioteca que fizesse leitura de teclas com intervenção do programador, e logo descobri que o próprio XNA possui a dita cuja.

A biblioteca usada foi justamente uma que acompanha o XNA. O resto foi WindowsForms puro.

No início, fiquei apenas fazendo uma esfera deslizar pela tela conforme o uso das setas. Logo depois eu comecei a criar mais e mais funções para fazer diversas coisas, como gravidade, arrasto, colisão, leitura do teclado, aplicação dos comando para a esfera, esticamentos,  etc. No processo, acabei até adquirindo alguns conhecimentos sobre física. Afinal, criar jogos é uma boa oportunidade de aplicar teorias da física.

Tudo utilizando imagens carregadas num "botão". No WindowsForms, essa é a melhor (ou única) maneira de representar sprites.

Quando percebi, já tinha um bom começo para criar um jogo. E foi o que fiz. Com o que eu já tinha, daria para criar sem grandes problemas uma versão simples do jogo clássico Lunar Lander. E assim nasceu o projeto WinForms Lander. Com este game, acabei juntando coisas que me interesso, como física, astronomia, games e desenvolvimento. Só assim para sentirmos motivados a criar algo.

Logo no início, ficou óbvio o quanto o WindowsForms é limitado para trabalhar com imagens. Quanto mais sprites e backgrounds existir, menos fluentes ficam os sprites. Isso se deve ao fato do WindowsForms atualizar as imagens na tela por conta própria. Você desloca uma figura, e a imagem se move sem você dizer quando isso deve ocorrer. O resultado não é tão ruim quanto parece, desde que se use pouquíssimos sprites numa tela.

Conforme fui desenvolvendo, fui aprimorando os códigos e arrumando a estrutura das funções. Posso dizer que o resultado ficou muito bom.Para contornar as limitações tecnológicas, fui adicionando conteúdo para tornar o jogo mais divertido, e atualmente o jogo já conta com várias "navinhas" e estágios, com variáveis diversas para aumentar o limitado desafio.

Inclusive, todas as naves foram desenhadas por mim num criador de ícones, e foi bastante divertido bolar as naves e os poderes especiais de cada uma (sim, eu fiz isso). Como se trata de um jogo de pousar corretamente, os poderes se limitam a auxiliar o pouso, como anti-gravidade, estabilização, etc.

Estou incluindo alguns efeitos sonoros também. E não tenho nenhuma biblioteca avançada em mãos para tocar os sons paralelamente e de qualquer jeito. Estou usando a biblioteca padrão para tocar sons em WindowsForms. É bem fácil de carregar um som e tocar, mas não é possível tocar áudios paralelamente. Portanto, tudo tem que ser feito controlando manualmente se o áudio está tocando, se deve trocar de áudio, etc. Difícil, mas recompensadoramente didático.

Posso dizer que o jogo está uns 70% pronto, faltando apenas aprimoramentos na jogabilidade e algum polimento no código. O jogo já salva e carrega, possui naves e fases secretas, e terá alguns desafios extras.

Quando terminar, ainda vou migrar o jogo para o XNA, que atualmente nem parece mais o bicho de sete cabeças de antes. E com certeza melhorarei o que o WindowsForms não permitiu.

Bom, este texto foi somente uma introdução. No próximo post, eu explico um pouco o que aprendi e aos poucos vou esclarecendo sobre lógica de jogo em geral e algumas decisões tomadas por mim durante o desenvolvimento.

Esta série não tem o intuito de ensinar a programar C#, nem mesmo de ensinar a criar jogos a torto e direito. Tenho a intenção de explicar mais coisas teóricas, que serão úteis mais para frente,  conforme eu for mostrando os códigos.

Você talvez deva estar se perguntando: "Se Windows Forms é ruim pra jogos, por que perder tempo com ele?"

Volto a salientar: isso tem somente fins didáticos. Eu ainda vou converter o jogo para XNA daqui alguns meses, e aí sim teremos um jogo decente (ou não).

Mas na verdade, se for analisar a simplicidade de alguns games antigos, o WinForms Lander até que não está indo mal.

Para quem já conhece C# e tem interesse em acompanhar a série, será necessário o Visual Studio 2008 ou o Visual C# Express Edition para programar. Ah, e instale o XNA 3.1 para utilizar a biblioteca. O C# Express e o XNA são gratuitos.

Após a conclusão do game, me aventurarei com o XNA. E com certeza criarei uma série de tutoriais sobre XNA.

Parte 2 - Fluxo e Update