por Fernando Lorenzon em 30/12/2009 as 17:07

forms_game1

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

Tags: , , , , , ,
Categorias: Desenvolvimento | 4 Comments »