Este ano irei terminar a minha pós-graduação em Games: Produção e Programação no SENAC, e tenho que fazer o meu Trabalho de Conclusão de Curso (TCC), quer será uma versão demo de um jogo. O projeto do TCC começou ano passado, quando fiz um Game Design Document (GDD) sobre uma idéia de jogo que tive, porém descartei esta idéia e este ano comecei a trabalhar em outra mais simples.

Embora eu não tenha finalizado o novo GDD, defini algumas coisas importantes para o início do meu projeto: o tipo de jogo que pretendo fazer, qual público-alvo desejo atingir e em qual plataforma irei focar. A idéia inicial era fazer um jogo em 3D, porém após pensar muito, decidi fazer um jogo de plataforma 2D para PC, com elementos de aventura e puzzles, focado no público de jogadores hardcore, porém também atendendo aos jogadores casuais (como jogos de plataforma geralmente fazem). Porém, para chegar nesta definição eu precisei passar por alguns meses pesquisando tecnologias.

Em outro post irei comentar mais sobre o processo de criação de um GDD,  além de detalhar mais o que estou fazendo. Neste post irei focar a primeira etapa que um desenvolvedor tem que definir, após ter conhecimento da idéia inicial do jogo: que tecnologia utilizar para programar o jogo. Abaixo estão algumas tecnologias que pensei em utilizar, porém por algum motivo desisti, até chegar à que realmente irei utilizar para o meu projeto de TCC:

• Unity: Uma poderosa Game Engine que tornou-se gratuita no final do ano passado, possibilitando que desenvolvedores independentes tivessem acesso a uma ferramenta de desenvolvimento de jogos profissionais. Em meu post sobre a Unity fica bem claro que é uma excelente Game Engine, inclusive quando escrevi aquele post estava pensando em utilizá-la no meu TCC, porém desisti. O motivo: a Unity é incrível, porém para fazer um bom jogo nela eu iria precisar de um modelador 3D desde o início do projeto, e eu estou fazendo o projeto sozinho e não sou modelador.

• C++/SDL/OpenGL: Após desistir de uma Game Engine, parti para uma das opções mais voltadas para programação, decidi tentar a combinação da linguagem de programação C++ com SDL, que eu aprendi na pós, e OpenGL para os gráficos 3D. Esta combinação possui vantagens, como a possibilidade de compilar para Windows e Linux. C++ é uma das linguagens mais utilizadas para programação de jogos, e OpenGL é muito utilizado em programação de jogos para consoles. Eu havia escolhido estas tecnologias por que eu iria aprender muito do que eu preciso para desenvolver jogos profissionais, porém desisti por um simples motivo: no momento eu não tenho muito tempo disponível para aprender a trabalhar com OpenGL, e eu não quero fazer algo mal feito.

• C++/DirectX: Aprender OpenGL era complicado e iria exigir muito tempo, então resolvi tentar utilizar C++ com DirectX, pois assim eu ainda estaria aprendendo mais sobre C++, além de eu já ter feito algumas coisas com DirectX na pós-graduação. Comecei a planejar o desenvolvimento de pesquisar as coisas seriam necessárias para o desenvolvimento de um game em 3D. Utilizando DirectX eu ficaria preso ao desenvolvimento para PC, porém não considerei este um problema, já que é um mercado bem amplo. Porém, comecei a ficar um pouco preocupado ao pensar em um simples detalhe: e os modelos 3D? Comecei a pesquisar alguns sites que possuem modelos gratuitos e pagos, eu até estava disposto a comprar modelos não muito caros, porém acabei desistindo de vez de fazer um jogo 3D, pois embora eu estivesse com uma tecnologia que eu conheço um pouco melhor, eu voltei ao problema que me fez desistir da Unity: pode ser que eu termine a programação do jogo, mas não tenha modelos 3D legais para utilizar.

• XNA: Desde o início eu pensei: se eu ficar desesperado, largo tudo e faço com XNA, pois tenho 2 jogos feitos com XNA em meu portfólio, além de participar de um projeto com XNA na Octopus Team. Depois de pensar muito sobre o meu jogo, sobre a verdadeira razão pela qual eu quero fazê-lo, eu decidi optar por algo que eu conheço bem e é simples de utilizar, para poder focar em fazer um jogo bom, ao invés de gastar muito tempo aprendendo uma tecnologia. Eu poderia até conseguir fazer algo com as tecnologias anteriores, e iria aprender coisas novas, porém não acho que o jogo iria ficar bom. Este motivo também me fez optar por utilizar gráficos 2D e fazer um jogo de plataforma, pois desenhos mais simples eu consigo fazer ou encontrar alguém para fazer.

Todo este processo de decisão de qual tecnologia eu iria adotar para o meu projeto custou caro: cerca de 3 meses de pesquisa e nenhum desenvolvimento. Embora eu tenha perdido todo este tempo, sendo que se eu tivesse pensado em utilizar XNA desde o início hoje eu já estaria bem adiantado no desenvolvimento, isto serviu para aprender diversas coisas em relação ao que priorizar em um projeto.

No início eu queria fazer um jogo para meu portfólio, por isso escolhi tecnologias que eu não conheço e acho importantes para eu aprender, porém agora estou com outra visão: não quero apenas mais um trabalho no meu portfólio, eu quero criar um produto que tenha chances reais de ser publicado e comercializado, e que talvez isto seja o início para eu abrir uma empresa.

Embora eu tenha escolhido uma tecnologia simples, e um modelo de jogo simples, vou focar no que realmente importa: divertir e entreter os jogadores com um jogo muito bom! Portanto, neste projeto o Game Design vai ser muito importante. Devido a esta importância eu ainda não finalizei muitas definições, pois quero fazer o melhor que puder. O que começou como uma idéia para um simples projeto de TCC, hoje se tornou o prelúdio de um sonho.

O SENAC São Paulo organizou sua primeira competição de jogos digitais, o e-Games, onde os concorrentes deveriam criar um jogo utilizando XNA. Além do jogo feito com XNA, foi necessário entregar um vídeo, documento de game design, apresentação, resumo e guia de instalação. O Download do jogo pode ser feito clicando aqui, ele necessita do .Net Framework 3.5 e Microsoft XNA Framework Redistributable 3.1 instalados para rodar, não é necessário instalar o jogo, apenas executar o SpaceShip4042.exe.

Tela inicial do jogo desenvolvido com XNA

O prazo para entrega foi na última sexta-feira, e eu decidi participar disto uma semana antes e sozinho. Ou seja, tive apenas uma semana para fazer tudo isso, além de ter que trabalhar e ir para a faculdade. Como estava sem tempo, decidi criar uma versão do meu jogo de celular SpaceShip 4042 em XNA, pois já tenho todas as imagens para criar o jogo, além de ter todo o conceito pronto, só foi necessário programar.

Depois de uma semana dormindo menos de 4 horas por dia, virando noites programando, o resultado não foi exatamente o que eu imaginei, mas consegui terminar meu jogo com tudo que a versão de celular tem, com excessão de som, pois tive dificuldades com isto e estava sem tempo. Além disso, no lugar de um High Score, fiz um Ranking top 5.

Embora eu tivesse apenas que programar, tive vários problemas por não conhecer muitas coisas no XNA e não ter tempo suficiente para estudar melhor. O maior problema que tive foi com a detecção de colisão por pixel. No JME existe uma função que verifica a colisião entre dois Sprites, inclusive existe o tipo de dado Sprite. Já no XNA não é tão fácil assim, não existe Sprite e método de detecção de colisão pronto.

O método de colisão que utilizei consiste em verificar se existe a interseção entre a área da imagem dos dois Sprites que estão colidindo. Uma vez que esta interseção existe, vem a parte mais complicada que é verificar se existe a sobreposição dos pixels que não são transparentes na imagem, utilizando um vetor com a cor da cada pixel da imagem. Não é tão complicado quanto parece, mas é bem chatinho de fazer.

Resolvi o problema do Sprite criando uma classe com os atributos que achei necessários para a fazer a nave, os meteoros, os itens e os tiros. Os principais atributos são: um Vector2D para a posição do objeto, uma lista de Texture2D para guardar todos as imagens que compoem a animação do Sprite, um Rectangle para ser utilizado na detecção da colisão, um vetor de Color com as cores da imagem, um bool para a visibilidade, e inteiros para armazenar vida, frame da animação e movimentação do objeto. Criei métodos para desenhar, mover, esconder, causar dano e verificar se o sprite “morreu”.

Outro problema que tive, mas que foi simples de resolver, foi a animação, pois o XNA também não possui algo que facilite isto como o incrível arquivo GameDesign do JME. Utilizando um inteiro, controlei a animação do Sprite em cada quadro. Também tive dificuldades com a criação das telas e sua maniulação. Criei uma interface para telas, e todas as telas implementam os métodos default do XNA: Update, Draw e LoadContent, além de um para controlar a inicilização das variáveis. A classe principal do jogo inicia todas as variáveis que representam as telas e tem responsabilidade de controlar a exibição de cada uma, de acordo com o estado do jogo.

Tela do jogo com os três tipos de Sprite criados

Se eu tivesse tido mais tempo, ou começado bem antes quando fiquei sabendo desde concurso, eu poderia ter feito muitas outras coisas e melhor, mas fiquei satisfeito em fazer um jogo em XNA em tão pouco tempo e sem conhecer tão bem as características desta tecnologia. Fiz muitas coisas básicas para um jogo 2D, e na minha opinião só faltou colocar som no jogo.

Assim como no JME, que tive dificuldades no começo, tive dificuldades com o XNA também, mas meus próximos jogos 2D nessas plataformas ficarão muito melhores, e provavelmente levarei menos tempo para programar, pois aprendi muitas coisas desenvolvendo para plataformas diferentes com tecnologias distintas. Praticamente tudo que utilizei aprendi fuçando nos exemplos do XNA Creators Club e nas dúvidas no forum, são ótimas fontes de informações.

Meu próximo passo agora é começar a estudar programação de jogos em 3D com C++. Este estudo é o primeiro passo para o meu TCC ano que vem, que provavelmente será um jogo em 3D com C++. Tenho algumas idéias para o jogo, mas nada decidido ainda, porém preciso aprender este tipo de programação, que eu tive contanto apenas no XNA para movimentação de modelos 3D simples na tela.

Este é o primeiro jogo que fiz para celulares, e também foi o primeiro projeto que terminei tudo o que eu planejava fazer. Fiz este jogo para a matéria de Jogos para Celular na pós-graduação utilizando Java Mobile (JME com CLDC 1.1/MIDP 2.0) e o Netbeans 6.7.1.

Como eu conheço Java, não tive problemas com a programação. A principal dificuldade inicial era entender como um jogo funciona em um celular, entender suas limitações e arquitetura. Por ser bem limitado, deve-se ter muita paciência e cuidado na programação para celular, para que o código não exija muito processamento e também para que as imagens fiquem “leves”.

O Netbeans ajudou muito no desenvolvimento do jogo, pois ele possui um tipo de arquivo chamado GameDesign, onde você importa imagens e cria sprites, cenários e cenas. Eu utilizei apenas para criar sprites do jogo, não precisei utilizar cenários e cenas.

Este projeto levou cerca de 2 meses para ficar pronto, porém não foram 2 meses de trabalho diário, eu programava um pouco por semana. Tive ajuda do David Felicino com as imagens das naves, tela de abertura, fundo do jogo e itens, e minha da namorada que me ajudou testando o jogo. Obrigado aos dois!

Clique aqui para baixar este jogo!

O objetivo do jogo é simples: permanecer o maior tempo possível e pontuar destruindo os meteoros ou desviando deles. O jogo acaba quando os 3 pontos de vida da nave chegarem ao fim, devido a colisões com os meteoros. Os meteoros também têm 3 pontos de vida.

Existem dois itens: um para ganhar 1 ponto de vida e outro para transformar a nave em “nível 2″. Neste nível 2, o jogo dobra a velocidade e os meteoros são destruídos com apenas um tiro. Se for atingido pelo meteoro, neste modo, o jogador não perde vida, apenas o item e volta a ficar com a nave “nível 1″. A velocidade do jogo também dobra se acontecer uma determinada situação.

A maior pontuação do jogar é sempre armazenada e pode ser vista através do meu “High Score”. Existe também uma opção para ver os controles e os créditos. O menu foi legal de fazer, pois o JME não dá suporte para menus apenas com imagens, então criei o menu com sprites que são trocados ou selecionados através dos botões “para cima” e “para baixo” do celular.

Além dos controles tradicionais (direcionais e botão central do celular), existe um suporte a eventos de toque na tela (apenas o jogo, o menu ainda não). O video abaixo é uma demonstração no meu celular, um Samsung Star S5230:

O jogo também possui uma verificação para talvez funcionar em um maior número de celulares sem precisar ser portado. A verificação é a seguinte: se a resolução da largura (width) da tela do jogo for inferior a 240, são desabilitados o som e a imagem de fundo e a imagem de abertura e os meteoros são imagens com um tamanho menor.

Este vídeo demonstra o jogo no emulador do Netbeans, em uma tela de 240 x 320:

Este vídeo demonstra o jogo no emulador do Netbeans, em uma tela de 176 x 220:

No segundo vídeo é possível ver tudo que foi reduzido da versão normal (primeiro vídeo) . É claro que é ambição demais querer que este jogo realmente funcione em vários celulares diferentes, mas pelo menos tentei fazer com que isto seja possível de alguma forma.

Este jogo funcionou nos seguintes celulares: Samsung Star S5230, Motorola A1200, Motorola V9, Sony Ericsson W380 (reduzido) e Sony Ericsson K550i (reduzido). Não consegui instalar no Motorola V3, ocorre um erro após transferir por bluetooth.

Existem alguns bugs que estou corrigindo e muitas coisas para polir, mas o jogo já está em sua primeira versão jogável. O principal problema é que, as vezes, ao entrar no jogo pela primeira vez em celulares mais simples, aparece uma tela branca. Neste caso basta voltar para o menu e entrar novamente, porém isto não ocorre sempre. Estou trabalhando nesta e em outras coisas para deixar este jogo o mais perfeito possível.

Desenvolver este jogo foi muito interessante, pois aprendi bastante sobre a arquitetura de um celular, programação com JME, algumas técnicas para diminuir o consumo do processamento, aplicação de design patterns no Java, gravar e ler informações no celular, e, principalmente, alguns dos vários problemas que podem acontecer ao testar o jogo fora do simulador.

Espero que gostem do jogo, este é o primeiro de muitos que pretendo fazer! Comentários são bem-vindos, principalmente se forem sobre bugs! Até mais!