http://www.youtube.com/watch?v=MBT1OK6VAIU

Os fontes podem ser baixados por SVN ou através de um tarball.

Lembrando que para poder abrir e executar o projeto é necessário o Visual Studio 2008 ou o C# Express 2008. Para o projeto do XNA, é necessário instalar também o XNA 3.1.

WinForms Lander:

Link do Projeto
Link dos Fontes
Link do Release 1.0

XNA Lander:

Link do Projeto
Link dos Fontes
Link do Release 1.0

Para que um jogo em XNA funcione em sua máquina, primeiro deve ser instalado o XNA Redistributable.

Download do XNA Redistributable 3.1.

Como prometido, disponibilizo o game bem como o código fonte.

Então, para que um jogo em XNA funcione em sua máquina, primeiro deve ser instalado o XNA Redistributable.

Download do XNA Redistributable 3.1.

Download do jogo XNA Lander

Download do código fonte do XNA Lander

Qualquer problema ou dúvida, estou a disposição para ajudar. Basta deixar um comentário.

Parte 6 – Audio

Em primeiro lugar, temos uma classe usada somente para tocar música, chamada de Song.

Para carregar o som, deve-se usar o Content.Load da mesma forma que uma textura, passando por parâmetro o caminho relativo do arquivo (sem extensão) a partir do diretório Content.

Segue o código:

Para tocar a música, deve-se usar a classe estática MediaPlayer, que é própria do XNA. Vejam todos os comandos possíveis:

Já os efeitos sonoros são utilizados de várias maneiras. Eu estou utilizando uma implementação própria do XNA 3.0, onde podemos instanciar uma classe SoundEffect de maneira similar ao Song. A diferença é que os arquivos devem ser do tipo wave.

Com isso, podemos tocar o som a qualquer momento usando a função Play().

O que ocorre neste Play() é criar uma nova instância daquele som e tocá-lo. Se o Play() for chamado várias vezes, vários sons são tocados ao mesmo tempo, em sobreposição. Isso não é muito útil, a não ser em situação em que o som deve ser tocado de maneira independente. Um exemplo disso é quando coletamos moedas no Super Mario.

Mas caso seja preciso tocar somente uma instância do som, usando repetição, aí a figura muda:

Com esta instância do som rocket, podemos aplicar loop no som e tocá-lo sem sobreposição de áudio. Ou seja, ao dar um novo Play(), o som corta e começa novamente. Tocando o som a partir da instância ele automaticamente se repete quando chega ao fim. Eu uso isso para ficar repetindo o som do foguete das naves enquanto ele está acionado.

Para tocar o som, basta fazer o seguinte:

Parte 5 - Mais Scenes
Parte 7 - Conclusão

A classe base Scene é bastante simples. Ela é uma classe abstrata, o que significa que você não pode utilizá-la diretamente. A única maneira de utilizar é extendendo a classe com o uso de herança. Por quê? Porque nela temos somente a estrutura básica, mas a implementação de cada scene depende do contexto do jogo. Aí sim criamos uma nova classe herdada dela, como por exemplo SceneTitle ou SceneAction.

Veja o código de Scene:

Como já falei, temos uma lista de fontes e uma lista de sprites. A classe Font assim como Sprite é também uma criação minha, que encapsula coisas mais chatas do framework.

Outra coisa que temos é uma cor de fundo em BackgroundColor, que a scene vai armazenar e o Game1.Draw() vai utilizar para pintar todo o buffer. Para quem não sabe, antes de pintar sprites na tela, o buffer é todo zerado com uma cor única, para limpar a sujeira toda dos Draws anteriores e começar do zero. Geralmente a cor padrão é preto, mas dependendo da tela você pode usar outra cor. Na tela de partida do jogo eu uso cinza, porque cada pedaço do HUD do jogo fica um pouco afastado do outro e o cinza acaba se destacando entre esses pedaços, simulando uma pequena borda:

A bordinha cinza na verdade faz parte do fundo cinza, e sobrou porque todo o resto foi pintado por cima, sobrando somente esses filetes entre os painéis do HUD.

Por padrão eu carrego a cor preta. Mas em qualquer lugar, a qualquer momento é possível trocar a cor.

Uma coisa necessária paar que a scene recém-criada possa ter seus sptires e fontes carregados pelo Game1, eu uso a linha de código no construtor:

Globals.MustLoadContent = true;

O Game1.Update() verifica o valor e se estiver true, volta para o Game1.LoadContent(). Senão, continua fazendo o update:

O que isso significa é que todas as vezes que crio uma nova scene (e imaginando que a utilizarei imediatamente) o jogo vai parar de rodar a scene anterior e carregar novamente os sprites desta nova scene. Assim que tudo carrega, faço isso:

Globals.MustLoadContent = false;

Algo tosco e básico, mas altamente inteligível ("entendível"). Não gosto de implementações que usam conceitos avançados de orientação a objeto  porque fica muito difícil de entender o que está acontecendo. Na verdade a orientação a objetos serve justamente para esconder código e facilitar/segmentar o desenvolvimento de sistemas. Aqui a idéia é ser didático, então tudo tem que ser simples.

Veja a implementação completa de SceneTitle, referente à primeira tela do jogo, com o menu principal e o título:

Como o código de Update() ficaria muito extenso, eu cortei parte dele, pois aqui o objetivo é entender como implementar uma scene inteira.

No LoadSpriteList() eu instancio os sprites que utilizarei e adiciono cada um na lista. Faço o mesmo com as fontes no método LoadFontList().

No caso dos sprites, os 3 únicos utilizados aqui são a figura que ilustra a tela, o cursor de seleção e a figura da nave atualmente selecionada. Como o sprite da nave selecionada eu utilizo durante todo o jogo, eu não preciso declarar este objeto na scene. Eu declaro em Globals. Por isso só existem essas duas declarações de sprite:

private Sprite titleScreen;
private Sprite cursor;

Porém, ao carregar os sprites que serã0 utilizados na scene, eu carrego junto com os dois anteriores o sprite da nave que está lá no Globals:

this.SpriteList.Add(this.titleScreen);
this.SpriteList.Add(this.cursor);
this.SpriteList.Add(Globals.SelectedShip);

Veja a tela de título:

Com isso encerramos este tópico sobre scenes.

Parte 4 - Scenes
Parte 6 - Audio

Na implementação de games complexos, algo que percebi na literatura do gênero é a adoção de scenes. Mas o que é uma scene?

Posso dizer que é um bloco de código independente que armazena dados e realiza um conjunto de funções pertinentes apenas àquela parte do jogo atual.

Mas para quê isso?

Com o uso de scenes, você pode separar cada pedaço do jogo em blocos, sendo que apenas um bloco é carregado e executado por vez.

Imagina ter que escrever toda a lógica de update de um game inteiro dentro do método Update()? Ou mesmo carregar todas as texturas do jogo inteiro no LoadContent()? Para um Asteroids, tudo bem. Mas imagina um de tamanho razoável como Braid sendo inteiramente escrito dentro de um único arquivo (Game1)?

Certamente ficaria extenso e confuso demais.

É aí que o conceito de Scene é utilizado, pois assim consegue-se separar o código e agrupar toda a lógica de cada tela/fase/cena do jogo em um único lugar, de modo que fique independente do resto e que sejam intercomunicáveis.

Por exemplo, a tela de menu tem toda uma lógica e grupo de gráficos próprios, que o resto do jogo não aproveitará. Aqui podemos agrupar tudo numa Scene. E quando o fluxo principal do jogo vai rodar pela primeira vez, a Scene é invocada e ela passa a comandar o jogo. Já no menu, ao selecionarmos o modo Arcade, a cena de menu chama a cena de jogo (ou da fase 1, dependendo do nível de agrupamento), e o menu "sai de cena".

É um conceito parecido com o teatro ou filme. Cada cena possui um grupo de falas, atuações, objetos, decoração figurantes e atc, que estão independentes do resto de tal maneira que não importa a ordem em que as cenas sejam filmadas. Depois basta rodar cada uma em ordem.

Dentro do desenvolvimento de games, uma scene geralmente é uma classe. Algumas engines já possuem uma implementação padrão para isso. Como o XNA é cru, temos que implementar nosso próprio conceito de scene.

Uma idéia que vi na literatura é criar uma classe que herda de GameComponent, pois esta classe possui todos aqueles métodos da classe Game, como Update(), LoadContent() e Draw().

A idéia com isso é que cada scene teria o poder de carregar sprites e renderizá-los sem a intervenção de Game1.

Mas quando eu fui tentar implementar isso, não consegui fazer com que o framework utilizasse os métodos corretamente. Por algum motivo, o comando Content.Load<>() usado para carregar textura e áudio não era acessível nestas classes extendidas. Ou seja, ainda não consigo carregar conteúdo fora da classe Game1.

Então eu decidi criar minha própria implementação de Scene, que considero ser menos poderosa, mas muito mais simples e fácil de onganizar, pois não depende de usar métodos obscuros do framework e de certa forma faz com que todo o processamento fique dentro de Game1, mas a implementação, fora.

Veja abaixo como funciona atualmente o fluxo das scenes no XNA Lander:

Clique para ampliar

Bem, a idéia geral é que toda a lógica do jogo seja de alguma forma executada a partir do Game1, e assim tudo vai funcionar bem.

O que eu fiz foi criar uma classe Scene contendo o seguinte:

- lista de Sprites;

- lista de Fontes;

- método LoadContent();

- método Update().

Para cada scene usada no jogo, eu crio uma nova classe e herdo de Scene. Aí eu declaro todos os sprites que serão utilizados na classe e adiciono na lista. Faço o mesmo com as fontes. Mas só declaro, e não as carrego, pois fora de Game1 eu não consegui. No método LoadContent() eu carrego ou inicializo qualquer outra coisa necessária para aquela scene funcionar (por exemplo, recarregar o combustível nave para uma nova fase caso seja a Scene de jogo).

No método Update() eu escrevo toda a lógica de fluxo de jogo para a Scene. Caso seja a Scene de menu, o Update() ficará lendo as teclas para mover o cursor pelo menu, além de verificar se o jogador pressionou Enter para selecionar a opção desejada.

Com isso, eu carrego a Scene desejada num objeto de visibilidade global (usando public static) chamada de CurrentScene, de modo que Game1 possa acessá-la. Aí, no método Game1.LoadContent(), eu chamo o CurrentScene.LoadContent(), e depois eu percorro a lista de sprites e carrego as texturas. No método Game1.Update(), invoco o CurrentScene.Update(). E no método Game1.Draw(), eu percorro a lista de sprites da CurrentScene e renderizo em ordem uma a uma. Isso tudo sem o jogo saber qual scene está sendo usada no momento, pois independente de qual seja, ela estará no objeto CurrentScene. O Game1 executa os mesmos passos para qualquer scene carregada. E isso é possível porque todas elas herdam de Scene e se comportam de maneira similar. Só seus conteúdos mudam.

Com isso, toda a lógica e sprites/fontes ficam contidos em cada scene, mas seu carregamento e execução ainda ficam  atrelados a Game1.

Após colocar isso em prática, basta codificar uma vez o Game1 e todo o resto do game passa a ser codificado através das Scenes.

Veja o void Initialize() do Game1:

Este código acima só rodará uma vez durante a execução de todo o game. Nada impede que você chame depois o método, entretanto. Então eu aproveito para carregar a primeira scene do jogo, que é a SceneTitle(), da tela de título e menu principal.

Vamos para o LoadContent():

Aqui no LoadContent() eu chamo o CurrentScene.LoadScene(), que pode ter qualquer carregamento que não seja gráfico.

Para carregar os sprites eu percorro a lista de sprites que carrego na Scene. Como não sei quais são os sprites a serem carregados, basta jogar todos eles na lista. Assim eu percorro ela carregando um por um. Faço o mesmo com as fontes também.

Vejamos o void Update():

Veja que aqui eu chamo o Update() que está no scene. Outra coisa que faço é verificar se devo chamar novamente o Game1.LoadContent(). Mas quando isso acontece? Simples, devo chamar sempre um LoadContent() quando carrego uma nova Scene. Assim que carrego qualquer scene, mudo um boolean Globals.MustLoadContent para true e o update volta novamente para o processo anterior, de carregamento dos sprites, para carregar os novos sprites da scene recém-carregada.

No Draw(), continua tudo tranquilo:

Veja que eu não renderizo o sprite ou font quando o Visible está como false. O resto é só renderizar cada sprite na lista da Scene carregada.

Aqui eu mostrei mais como o jogo invoca e usa as scenes, mas não expliquei a implementação de cada Scene internamente. No próximo post eu falo mais sobre isso, inclusive com exemplos de código.

Parte 3 - Codificação Básica
Parte 5 - Mais Scenes

Aqui já podemos ser mais práticos. Crie um projeto XNA limpo e abra a classe Game1.

O que vemos nela é aquilo explicado no post da parte 2.

Para fazer um sprite se mover na tela, precisamos criar um Rectangle, um Texture2D e um KeyboardState.

Para começar, vamos criar uma textura. Crie ou pegue uma figura qualquer em png ou jpg e renomeie como "quadrado.png" (ou .jpg).

Se quiser, use esta figura:

Agora clique com o botão direito na pasta Content pelo Solution Explorer do Visual Studio e selecione Add >> Existing Item:

Selecione o quadrado que você acabou de salvar.

Vamos ao código:

Lá no início da declaração da classe encontram-se dois objetos declarados:

GraphicsDeviceManager graphics;
SpriteBatch spriteBatch;

O GraphicsDeviceManager é usado pelo framework e até agora só vi ser utilizado para ajustar a resolução da tela. O SpriteBatch é utilizado para renderizar sprites na tela, dentro do método Draw().

Vamos criar os objetos. Abaixo da declaração dos objetos que citei acima, digite o seguinte:

Rectangle rectangle;
Texture2D texture;
KeyboardState keyboardState;

Agora temos que carregar cada objeto. O rectangle pode ser instanciado no método Initialize():

this.rectangle = new Rectangle(300, 300, 50, 50);

Os números do parâmetro são respectivamente: Posição X, Posição Y, Largura, Altura. Ou seja, estou criando um quadrado com 50 pixels de lado posicionado mais ou menos no meio da tela.

A textura texture pode ser carregada dentro do método LoadContent():

this.texture = Content.Load<Texture2D>("quadrado");

Note que o comando Content.Load deve receber como tipo (<Type>) a classe correspondente ao conteúdo audiovisual a ser carregado. No caso, se trata de uma textura 2D. Como parâmetro, deve receber o path a partir do Content + o nome do arquivo SEM a extensão! No caso, se você tivesse criado uma pasta dentro de Content chamada Imagens e colocasse a figura dentro, então a maneira correta para carregar seria:

this.texture = Content.Load<Texture2D>("Imagens/quadrado");

Agora temos que fazer o quadrado se mover pela tela conforme o usuário pressiona as setas do teclado. Para isso, vamos escrever o seguinte no método Update():

this.keyboardState = Keyboard.GetState();

if (this.keyboardState.IsKeyDown(Keys.Up))
{
this.rectangle.Y--;
}

if (this.keyboardState.IsKeyDown(Keys.Down))
{
this.rectangle.Y++;
}

if (this.keyboardState.IsKeyDown(Keys.Left))
{
this.rectangle.X--;
}

if (this.keyboardState.IsKeyDown(Keys.Right))
{
this.rectangle.X++;
}

O que estou fazendo é a cada Update obter o estado do teclado para verificar quais teclas estavam pressionadas naquele momento. Para isso, devemos carregar o objeto keyboardState com o método Keyboard.GetState().

Aí é só verificar se a seta está pressionada e dependendo da direção, incrementar ou decrementar o X ou o Y daquele quadrado.

Por último, falta renderizar o quadrado na tela. Para isso, escreva o seguinte dentro do método Draw():

this.spriteBatch.Begin(SpriteBlendMode.AlphaBlend, SpriteSortMode.BackToFront, SaveStateMode.SaveState);
this.spriteBatch.Draw(this.texture, this.rectangle, Color.White);
this.spriteBatch.End();

O que estamos fazendo acima é iniciando a renderização com o spriteBatch.Begin, renderizando com spriteBatch.Draw e finalizando com spriteBatch.End. Só depois do end algo aparecerá na tela.

O que o método spriteBatch.Draw recebe é a textura a ser renderizada, o quadrado que receberá a textura e a cor da textura. Se você quiser manter a cor original, use a cor White. Rode e veja se o quadrado se move. Eis o código completo de Game1:

Parte 2 - Noções Básicas
Parte 4 - Scenes

Com Visual Studio e o framework instalados, abra o Visual Studio e clique m File >> New Project.

Então escolha um projeto do tipo XNA Game Studio 3.1:

Dê um nome para o projeto e clique em OK.

O Visual Studio vai abrir o projeto e já vai ter criado para você um arquivo chamado Game1.

Este arquivo é uma classe que herda da classe Game.

É neste arquivo que toda mágica acontece. A thread principal do jogo funciona atrelado a ela. Enquanto eu desenvolvia, tentei criar outras classes herdando de Game, mas cada uma fica presa na thread principal e não é possível alternar a execução entre elas. Pelo menos eu não consegui.

A classe Game1 começa com 5 funções criadas:

- void Initialize();
- void LoadContent();
- void UnloadContent();
- void Update(GameTime gameTime);
- void Draw(GameTime gameTime).

Cada uma delas deve ser usada apropriadamente para que o jogo funcione corretamente. Mas nada impede que você as invoque a qualquer momento. Eu mesmo tive alguns problemas em que a função Draw não era invocada quando necessário, e eu simplesmente comecei a invocá-la explicitamente.

void Initialize()

Neste método, você deve escrever todo o código de inicialização do jogo. Esta função roda somente na primeira execução do jogo. Para quem programa web client ou windows forms, isso seria o equivalente ao form_load().

Aqui poderemos informar a taxa de FPS pretendida no jogo, carregar a tela principal, inicializar as variáveis globais do jogo e etc.

void LoadContent()

Este método é responsável por carregar todo conteúdo audiovisual do jogo. A chamada deste método pode ocorrer várias vezes durante a execução do programa.

No próprio projeto criado, existe um diretório do projeto chamado Content, onde todo o conteúdo externo usado no jogo deve ser guardado para ser carregado apropriadamente.

void UnloadContent()

Aqui você pode escrever código para descarregar variáveis do jogo bem como tirar da memória o conteúdo gráfico. Como o jogo roda em .Net e este possui coletor de lixo automático, dependendo da sua implementação do jogo, este método é inútil.

void Update()

Método principal onde o fluxo de jogo ocorre. É este método que é chamado 60 vezes por segundo. Toda a lógica da partida do jogo ou de qualquer outra tela dinâmica deve chamada por aqui, pois o próprio jogo se encarrega de disparar este método de acordo com as configurações do FPS.

void Draw()

Aqui é onde o conteúdo gráfico é renderizado. Entenda conteúdo gráfico como texturas e fontes de texto.

----

Então, não é necessário usar estes métodos exatamente como descrito. É perfeitamente possível carregar conteúdo gráfico no Update(), bem como botar lógica de jogo no Draw(). A idéia é que o framework saberia o momento certo de invocar automaticamente cada um destes métodos e encadear a execução com métodos de outras classes herdadas de GameComponent , que possui estes métodos também.

Para começar a desenvolver o jogo, precisamos aprender a usar sprites, que são os gráficos 2D.

Para renderizar alguma coisa 2D na tela, é necessário um Rectangle e um Texture2D.

Rectangle é uma classe que representa um retângulo simples e invisível. Você consegue mover o rectangle alterando seus valores X e Y. E também consegue alterar seu tamanho através dos atributos Width e Height. É a partir dele que teremos o controle de colisão e aplicação de física.

O Texture2D é uma figura ou mesmo um array de cores (que não deixa de ser uma figura). O Texture2D é visível, porém, não se move nem muda o tamanho.

Para renderizar a textura (no método Draw), é necessário informar um retângulo em que ela será impressa. Como o retângulo muda de posição e de tamanho, a textura sendo constantmente aplicada em cima dele acada se movendo e mudando o tamanho por consequência. Ou seja, o destino de uma textura será sempre um retângulo. Então, se mudarmos a posição deste ao longo do jogo, o que veremos na prática é a textura se movendo.

Como podem ver, é tudo muito básico, simples e cru.

Para tudo isso ficar mais fácil, seria interessante ter uma classe Sprite que tivesse um Rectangle e um Texture2D como atributos. Como eu já tinha esta classe do jogo anterior, eu só tive que mudar o PictureBox para Rectangle e Image para Texture2D.

Para incrementar, podemos criar uma Property X na classe Sprite em que o get retorne o Rectangle.X e o set aplica o valor ao Rectangle.X.

Podemos fazer isso para o Y também, lógico.

Assim, teremos uma classe Sprite com seu retângulo, sua textura, e sua posição no plano 2D do jogo.

Parte 1 - Introdução
Parte 3 - Codificação Básica

Enfim, depois de algum tempinho e de alguns problemas, estamos de volta. E nada melhor que voltarmos aos nossos posts sobre desenvolvimento (pra alguns, talvez não).

Como fazer seu próprio jogo? Nesta série explicarei como criar um jogo usando XNA. No final dos posts da série eu disponibilizarei todo o código fonte bem como o jogo pronto para jogar.

Lembram-se do WinForms Lander, o jogo feito em Windows Forms que expliquei aqui há alguns meses?

Na época eu havia tentando fazer um jogo usando ferramentas que não eram exatamente para este fim, mas que eu dominava bem. Ao longo dos 7 posts, eu expliquei um pouco sobre o desenvolvimento de um jogo de modo geral, passando pelos comandos, fluxos de update, colisão e etc. Quem não viu, eu recomendo muitíssimo a leitura, disponível ali no link acima.

Em algum momento eu mencionei que no futuro eu faria o game totalmente em XNA.

Há algumas semanas eu estou fazendo isso e o jogo está quase 100% convertido, permitindo assim que eu inicie uma nova série de posts sobre desenvolvimento em XNA.

Como o básico eu já expliquei nos posts anteriores, nesta série vou focar mais na tecnologia do XNA que em desenvolvimento de games de modo geral. Lembrando que este não é um guia de como fazer um jogo do início ao fim, nem sobre XNA avançado. Já existem muitos blogs por aí postando sobre XNA e eu não vou competir com eles. Minha idéia será mostrar alguns problemas de desenvolvimento que eu tive bem como as soluções que adotei para resolvê-los.

Para começar, quem quiser de alguma forma acompanhar terá que baixar o Visual Studio 2008 ou 2010 e o XNA 3.1.

Vamos falar um pouco do XNA. O que é XNA? É um framework de desenvolvimento de games. E o que isso significa? Bem, no contexto de desenvolvimento de sistemas, um framework é um conjunto de bibliotecas e estruturas de dados que juntas direcionam ou mesmo forçam o desenvolvedor a codificar de uma determinada maneira. Se você usar o framework à risca, ganhará muita produtividade, mas como todo framework, há alguma limitações em que você certamente esbarrará.

O XNA não é a melhor ferramenta do mundo para desenvolver grandes games, mas também não é paga, o que é uma grande vantagem. O legal é que o XNA usa o Visual Studio e a linguagem de programação C#, que são consideradas juntas a melhor e mais produtiva ferramenta de desenvolvimento de grandes aplicações hoje em dia por muita gente (eu incluso). Principalmente se considerar o uso de interfaces gráficas. Isso tudo está ao alcance de você ao criar seu game usando XNA. A Microsoft é f*da!!

Porém, mesmo usando o Visual Studio, você definitivamente não usará nenhum tipo de auxílio visual para construir cenários e layouts de tela em geral. Tudo deve ser feito via código.

Aqui foi onde eu mais sofri nesta migração do WinForms Lander. Transformá-lo no XNA Lander significou deixar de lado toda a facilidade de construir telas do Visual Studio e substituir tudo por sprites posicionados na mão, passando o X,Y de cada um e fazendo ajustes às cegas, para então executar o game e ver como ficou o layout.

Nesta parte não tem muito o que chorar mesmo, pois ajustar o layout é relativamente rápido em comparação com desenvolver o resto do game.

Como eu já tinha os fontes do jogo original, aproveitei todo o código de cálculo de física bem como a maioria das classes. Só precisei reescrever os layouts e as chamadas para cada tela, pois no XNA as coisas mudam muito na maneira como você carrega conteúdo na tela e os renderiza.

Usando o XNA, a coisa que eu notei mais rapidamente foi o ganho em performance com relação à versão antiga do game. Pois Windows Forms é usado primariamente para exibir telas estáticas. Mas pelo que eu vejo por aí, o XNA não é mais rápido que as grandes engines comerciais, como a Unreal Engine ou a Unity. Portanto, se você almeja fazer o novo World of Warcraft killer, esteja avisado (toda salsinha quer fazer um WoW). Querem uma dica, comecem tentando fazer um Pong ou mesmo Tetris.

Bem, o intuito deste port para XNA é de apenas conhecer melhor a ferramenta, e assim que o jogo estiver pronto e fiel à versão em Windows Forms, vou começar a criar a versão melhorada, com recursos adicionais, como cenários de fundo, sons melhores, mais missões e tudo o que o XNA permitir e eu conseguir fazer.

Por hoje é só. Aguardem a parte 2 com alguns códigos e uma visão geral das classes do XNA.

Parte 2 - Noções Básicas

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