Introdução

A indústria de software de vídeo games é contabilizada nos USA em

torno de 6 bilhões de dólares. Se incluirmos consoles, portáteis,
aplicativos e venda de acessórios, em 2006 a indústria de vídeo games
gerou um retorno de cerca de 12,5 bilhões de dólares, excedendo a
marca do recorde anterior que era de cerca de 2 bilhões de dólares.

Com o Microsoft XNA, pela primeira vez um desenvolvedor que não

fosse profissional de game pode criar um jogo single ou multiplayer que
pode rodar tanto no PC quanto no console Xbox 360.

Esses dois fatos por si só, podem ser razão suficiente para que qualquer
um tenha interesse em aprender XNA e tornar-se um desenvolvedor de
jogos, tentando obter uma fatia do mercado que é mais promissor do
que a indústria de criação de filmes de Hollywood.

Contudo, sejamos justos e sinceros. Infelizmente, há poucas portas

abertas nesta área: comparando-se um cargo de programador de jogos
para cada cem cargos de programadores de outras atividades. Pior que
isso, em média, a indústria de desenvolvimento de jogos paga menos do
que outros tipos de desenvolvimento.

Após digerir esses fatos, se você ainda acha que trabalhar como
desenvolvedor de jogos pode ser interessante e valer a pena, então
continue nesse caminho. É provável que com o passar de pouco tempo,
a situação de quantidade de vagas e remuneração mude bastante,
sobretudo em nosso país. Mas é sempre bom pesar os riscos e os
retornos!

Há também boas notícias: como a promessa da Microsoft de abrir

mercado, permitindo que qualquer um comercialize seus jogos para
outros, logo haverá um potencial de 10 milhões de usuários (Janeiro de
2008) para seus jogos caseiros.

O que é XNA?
XNA é uma brincadeira de palavras. A sigla significa “isso não é uma
sigla”. O mundo Microsoft é tão cheio de siglas que eles decidiram
criar um nome que parecesse uma sigla, mas não é, só de
brincadeira.
Mas XNA é muito mais do que isso. O conceito inovador de trazer para o
desenvolvedor padrão o poder de criar seus próprios jogos para o Xbox
360 é uma grande inovação tecnológica, a qual traz muitos esforços da
Microsoft para estabelecer uma comunidade ativa para criadores de
jogos (unindo ambas as comunidades de programadores de jogos para
Windows e para Xbox 360) e também estabelecendo programas em
áreas acadêmicas para dar suporte a instituições que desejam criar
cursos usando consoles Xbox 360 como base.

Esses esforços tornaram-se óbvios quando notamos que o Microsoft XNA

Game Studio pode ser adquirido gratuitamente pelo site da Microsoft,
em http://www.microsoft.com/XNA. A Microsoft também oferece
conteúdo de jogos gratuitos, incluindo tutoriais de vídeo, kits de
inicialização (que podem ser configurados pelo programador), exemplos,
e outros conteúdos de suporte no XNA Creator’s Club:
http://creators.XNA.com.

O último passo em fazer o Microsoft LIVE conhecido como um “Youtube

para jogos” é a habilidade de submeter os jogos criados por você para
Xbox LIVE e distribuí-los (ou mesmo vendê-los) para qualquer um que
esteja em conexão com o LIVE. Nenhuma outra comunidade de
programadores de jogos não-profissional é tão excitante, como o XNA
Game Studio lançando atualizações freqüentes com novos conteúdos no
site XNA Creator’s Club!

O grande segredo por trás do sucesso do XNA é que ele é fácil – muito
mais fácil do que qualquer API para console, e também mais fácil do que
qualquer API para Windows, devido ao nível de abstração que ele provê
para detalhes que com os quais você tem que se preocupar em outras
APIs. XNA usa o mesmo ambiente de desenvolvimento integrado (IDE) –
XNA Game Studio Express – e o mesmo framework para
desenvolvimento de jogos tanto para Windows como para Xbox 360, o
que assegura um alto grau de compatibilidade. Contudo, há diferenças
em nas camadas mais baixas. O console Xbox 360 roda uma versão
compacta do Framework DotNet, então você deve ser cuidadoso: nem
todas as funções disponíveis para Windows irão funcionar no Xbox 360.

Como nasceu o XNA?

Vamos fazer uma jornada de volta aos dias do DOS no PC. Quando
programar jogos, demonstrações gráficas, e coisas do tipo no DOS, os
programadores tipicamente tinham que escrever código de baixo-nível
para conversar diretamente com a placa de som, placas gráficas e
dispositivos de entrada. Isso era tedioso e os códigos resultantes eram
candidatos a apresentarem erros porque os fabricantes diferentes
criavam seus hardwares de forma diferente como, interrupções de BIOS,
portas E/S, e bancos de memória – assim, o código poderia funcionar
em um sistema e não funcionar em outro.

Mais tarde, a Microsoft lançou o sistema operacional Windows 95. Muitos

programadores de jogos foram céticos quanto a escrever jogos para
Windows – e com razão – porque não havia mais como se comunicar
com o hardware em baixo nível para realizar tarefas de forma rápida. O
Windows 95 tinha um modelo de memória protegida que impedia os
desenvolvedores de acessar diretamente as interrupções de hardware
de baixo-nível.

Para resolver esse problema, a Microsoft criou uma tecnologia chamada

DirectX. Primeiramente foi chamada Windows Game SDK, mas
rapidamente foi dividida em DirectDraw, DirectSound, e DirectPlay,
recebendo então o nome de Direct “X”. O DirectX 1.0 nasceu poucos
meses depois do Windows 95 ser lançado.

Graças ao DirectX, desenvolvedores tinham uma forma de escrever

jogos com um código fonte que funcionaria em todos os PCs
independentemente de seus hardwares. Os fabricantes de hardwares
estavam interessados em trabalhar com a Microsoft no sentido de
padronizar uma interface para acessar seus hardwares. Eles criaram
drivers de dispositivos com os quais o DirectX conseguia interagir, então
todo o trabalho que antes era feito pelos programadores de jogos, agora
era feito por eles, e esses programadores poderiam gastar seu tempo
fazendo o que eles realmente queriam – programar jogos! Os
fabricantes chamaram essa metodologia de Hardware Abstraction Layer
– HAL (Camada de Abstração de Hardware). Eles também
desenvolveram um Hardware Emulation Layer – HEL (Camada de
Emulação de Hardware), a qual emulava hardware através de software,
para o caso em que o hardware não estivesse presente. É fato que, isso
fazia o processamento mais lento, mas por outro lado, permitia que
certos jogos rodassem em máquinas que não tivessem hardware
especial.

Depois de alguns anos a Microsoft lançou DirectX 3.0, o qual rodava em

Windows NT 4 assim como em Windows 95. Como parte dessas
atualizações, eles introduziram o Direct3D. Ele permitia aos
desenvolvedores criaram objetos 3D dentro de mundos 3D. O DirectX 4
nunca foi lançado, mas o DirectX 5 foi lançado em 1997 e depois
recebeu algumas atualizações e melhorias para trabalhar com o
Windows 98.

Quando o DirectX 8 entrou em cena no ano 2000, alguns dos novos

hardwares gráficos possuíam vertex e pixel shaders. Como resultado, a
Microsoft adicionou uma forma de passar código com comandos
especiais para essas tecnologias diretamente para o hardware. Através
de código assembly, o desenvolvedor de jogo poderia manipular os
dados principais enviando-os para a placa gráfica. Esse código assembly
era utilizado diretamente pelo hardware gráfico.

Quando não havia hardware gráfico, os jogos ficavam lentos, mas ainda
assim bem flexíveis. Depois, quando a renderização por hardware
tornou-se proeminente, os jogos ficaram mais rápidos, mas eles não
eram mais tão flexíveis fazendo com que todos os jogos parecessem ter
“a mesma cara”. Agora com shaders, a velocidade dos hardwares foi
combinada com a flexibilidade para cada jogo de renderizar e iluminar
seu conteúdo 3D de forma diferente.

Chegamos então aos dias atuais do DirectX: estamos na versão 9 e 10.

O DirectX 10 foi lançado ao mesmo tempo que o Windows Vista. De
fato, o DirectX 10 só funciona no Vista. Isso tem muito a ver com o fato
de a Microsoft ter feito grandes mudanças no modelo de drivers para o
sistema operacional. O DirectX 10 também requer o hardware Shader
Model 4.0.

O Xbox 360 roda no DirectX 9 com adicional suporte ao Shader Model

3.0. DirectX 9 é o fundamento para o Managed DirectX, uma API –
Application Program Interface (Interface de Programação de Aplicação)
– que expôs a funcionalidade core (principal) para os programadores do
Framework DotNet.

O Framework XNA usou as lições aprendidas do Managed DirectX e usou

esse fundamento como um ponto de partida. Para ser claro, o XNA foi
criado do zero, sem utilizar o Managed DirectX. Ele não utiliza os
mesmos namespaces do Managed DirectX. Embora o XNA utilize o
DirectX 9 como pano de fundo, não há referências à API do DirectX
dentro do XNA, como havia no Managed DirectX.
Planejamento de jogos e programação básica

Antes de começarmos a criar jogos, é necessário planejamento e

conhecimento dos conceitos fundamentais de programação de jogos.

Planejando o jogo

Os esforços envolvendo a criação de jogos bons começam muito antes

da fase de codificação. Depreciado por programadores de games não-
profissionais, o planejamento é a fase mais importante do seu projeto
de desenvolvimento de jogo. É por isso que essa fase define as
diretrizes para todos os estágios subseqüentes.

Antes de pensar que tipo de jogo você irá criar, você deve escolher seu
público alvo, porque essa escolha definirá a direção para o seu total
esforço de desenvolvimento do jogo.

O Grupo NPD (http://www.npd.com), em suas pesquisa, dividiu o

mercado em 6 categorias: jogadores assíduos (que constantemente
jogam e são responsáveis pela maioria do mercado de vendas),
jogadores de console ávidos (que compram os principais consoles de
jogos, e podem jogar jogos de console por várias horas por dia),
jogadores massivos (que normalmente compram apenas jogos
“blockbuster”), jogadores de jogos portáteis (como o nome diz, eles
preferem jogar jogos usando dispositivos portáteis), jogadores
secundários (que geralmente não compram jogos, e jogam jogos
comprados por outras pessoas), e jogadores pouco freqüentes (que
jogam jogos muito raramente).

Nós não faremos um estudo intensivo desses segmentos, mas vamos

apontar alguns pontos significantes sobre as duas categorias limites:

Jogadores pouco freqüentes: Esses jogadores também conhecidos como

“jogadores casuais”, jogam jogos que costumam ser fáceis, sem estórias
complexas e que apresentam desafios diretos para cada nível, dando ao
ao jogador a impressão de completá-los em rodadas rápidas. Jogos para
esse tipo de mercado geralmente não dependem de gráficos 3D bem
detalhados ou efeitos de som extraordinários, e incluem jogos de carta
(poker, copas fora, paciência, e por aí vai), quebra-cabeças (Tetris,
Sudoku, palavras-cruzadas, e por aí vai), jogos de tabuleiros
(mahjongg, xadrez, damas, e por aí vai), e similares. Não se engane
com esses jogos: embora eles pareçam fáceis de desenvolver, eles
dependem de níveis balanceados e boa jogabilidade para manter o
atenção dos jogadores, que pode ser difícil de segurar.

Jogadores Assíduos: Esse grupo, também chamado “jogadores

intensos”, encaram os jogos de forma séria. Eles são normalmente
movidos por desafios difíceis e uma boa estória que os ajuda a manter-
se imersos no mundo do jogo. Jogos para esse tipo de jogadores
normalmente incluem ambientes 3D extremamente detalhados,
combinados com músicas de fundo e efeitos de som, e um uma
jogabilidade intensa com muitos desafios.

Uma vez escolhido o seu público alvo, o próximo passo é definir o

gênero do jogo. Há muitas divisões de gêneros de jogos, mas ainda
baseando-se na pesquisa do Grupo NPD, os gêneros de jogos mais
vendidos são mostrados na tabela a seguir (realizada em 2005):

Gênero Computador Console

Estratégia 30,8%
Entretenimento para 19,8% 9,3%
crianças e famílias
Atiradores 14,4% 8,7%
RPG 12,4% 7,8%
Aventura 5,8%
Ação 4,7% 30,1%
Esportes 3,7% 17,3%
Corrida 11,1%
Aviação 4,7%
Outros 8,4% 11%

Repare que os melhores vendidos para computador não são necessários

os melhores vendidos para console. O bom do XNA é que você pode
trabalhar com ambas as plataformas.

Escolher o mercado alvo e o gênero do jogo ajudará a você a afunilar

suas escolhas sobre que tipo de jogo irá desenvolver. E, se você já tem
um jogo em mente, pensar sobre esses pontos ajudará a você a refinar
suas idéias para o próximo passo: definição do time envolvido no
projeto de desenvolvimento do jogo, e escolher o seu lugar nesse time.
Isso nos leva a um segundo conceito importante no desenvolvimento de
um jogo: o time de desenvolvimento.

Pequenos times, ou mesmo uma simples pessoa multifacetada, podem

criar jogos para jogadores casuais, enquanto jogos para jogadores
intensos podem envolver um time com dúzias de pessoas como
especialidades em diferentes áreas.

Embora você possa estar apto a desenvolver jogos por você mesmo, o
desenvolvimento de jogos é sempre mais do que simplesmente código.
Você precisará de: gráficos bonitos, efeitos de som; e você necessitará
criar os níveis do jogo, isso apenas para falar algumas poucas atividades
diferentes em um projeto de jogo. Em um projeto de desenvolvimento
de um grande jogo, e você necessitará de habilidades tais como as que
se seguem:

Gerente de projeto: Alguém deve estar no comando para controlar o

tempo, o escopo, os recursos necessários, as comunicações, a
coordenação entre os membros do time, e por aí vai. Mesmo que você
esteja desenvolvendo um jogo com alguns poucos amigos, é crucial
definir “quem está no comando” para resolver os problemas e definir a
direção do projeto.

Escritores de scripts: O escritor de scripts é responsável por escrever a

estória do jogo, definindo os desafios a serem enfrentados e os
mistérios a serem resolvidos. Eles normalmente ajudam a definir todo o
pano de fundo do jogo, como os personagens, os diálogos, e as divisões
dos níveis.

Criadores de níveis: Criadores de níveis normalmente utilizam

ferramentas para criar e definir cada um dos níveis do jogo, de acordo
com as premissas de programação dadas pelo time de codificação e a
estória escrita pelo escritor de scripts.

Artistas: Artista é uma categoria muito ampla, envolvendo criadores de

conceitos de arte, criadores de arte de computador, pessoas
responsáveis por texturização (criação de texturas para paisagens em
2D e “peles” de modelos 3D), coloristas de computador, e por aí vai.
Esse pessoal cria também a página de abertura e os menus do jogo e
também imagens estáticas, e podem também criar a arte para o time de
marketing do jogo.

Modeladores: Essas pessoas são responsáveis por criar modelos 3D para

os jogos seguindo o conceito de arte e arte de computador.

Animadores: A criação de modelos 3D não é a mesma coisa que a

animação deles, por isso alguns times incluem especialistas em criar o
modelo de animação para o jogo. Esse time também cria as cuts-scenes
– as seqüências de vídeo apresentadas no começo do jogo e em especial
pontos do jogo, como quando um jogador vence um desafio, ou no
começo ou fim de nível.

Músicos: Essa também é uma categoria bastante abrangente, que tem a

responsabilidade de escrever (e tocar) as músicas de fundo do jogo e de
cada ambiente e, também de criar as vozes e os efeitos de som para o
jogo.

Programadores: Alguém deve estar responsável por escrever o código

do jogo, incluindo todos os cálculos matemáticos e físicos necessários
para suportar os efeitos do jogo desejados.

Testadores: Não é recomendável que a mesma pessoa que escreve o

código seja responsável por testá-lo. O objetivo dos testadores é
encontrar o máximo de bugs que eles puderem, tentado realizar coisas
não esperadas dentro do jogo para que o os bugs apareçam no processo
de desenvolvimento do jogo ao invés de aparecerem durante a
utilização do jogo pelo usuário.

Essa lista continua, incluindo pessoas responsáveis por preparar e

conduzir os esforços de marketing para o jogo, pessoas que lidam com
os canais de publicidade, e o pessoal que cuida da infra-estrutura de
hardware e software para o desenvolvimento do jogo e às vezes, para a
publicação do jogo (se o projeto inclui um servidor de jogo de Internet,
por exemplo).

Evoluindo seus planos para um grande jogo

Escolher um alto de mercado para o jogo e um gênero e selecionar as

pessoas certas para o projeto de jogo não são os únicos pontos chave
que você precisa pensar quando planeja um jogo.

Um grande número de informações está disponível nos livros e na

Internet sobre planejamento de jogos. Aqui, será mostrada uma visão
geral de alguns pontos que você simplesmente não pode deixar de
considerar quando faz o planejamento do seu jogo.

Objetivo do jogo: Tudo começa com uma definição clara do objetivo do

jogo: vencer a copa do mundo, vender o mago do mal e evitar a
destruição da do mundo, salvar quantos lemmings quantos você puder a
cada nível. Esse objetivo em última análise guia a criação de uma
estória do jogo e define se esse é um novo inovador ou apenas uma
clone de um jogo best-selling.
Critério de finalização: Além do objetivo do jogo, é também importante
definir o critério de finalização do jogo: quando o jogo termina, que
inclui o critério de vitória do jogador (normalmente relacionado com o
objetivo do jogo) e o critério de derrota (quando o número de vidas
chega a zero, quando o tempo expira, e por aí vai). Quando se define o
critério de derrota do jogo, é também importante definir como o jogador
retornará a uma nova partida. Prover um mecanismo de salvamento ou
auto-salvamento é crucial para jogos longos, mas pode diminuir o
desafio para jogos cursos tais como xadrez ou paciência.

A instalação do XNA Game Studio

Antes que você possa codificar seus próprios jogos, você deve instalar
seu ambiente de desenvolvimento. O XNA Game Studio permite que
você crie seus próprios projetos de jogos usando um único ambiente.
Melhor do que isso, ele é completamente grátis.

Primeiramente você ter uma versão do Visual Studio 2005 ou 2008 que
permita que você possa desenvolver programas em C#. Isso é
necessário porque o XNA utiliza o C#.

O XNA requer que o último Service Pack para o Visual Studio esteja
instalado. Vá ao site da Microsoft onde você baixou o Visual C# Express
Edition, e procure pela seção de downloads de Service Packs para o
Visual Studio. Escolha o Service Pack mais atual faça download dele e o
instale no seu computador.

Finalmente vá até a página da Microsoft relativa ao XNA (costuma ser

http://creators.xna.com/education/newtoxna.aspx) mas como as coisas
mudam bastante na Internet, caso tenha dificuldade de achá-la, dê uma
olhadinha no Google. 

Estando na página da Microsoft de download do XNA (importante: evite

de baixar tanto o Visual Studio Express como o XNA de outras páginas
que não seja da Microsoft, você estará fazendo um favor a si mesmo,
em termos de segurança e confiabilidade). Escolha fazer download do
XNA Game Studio (2.0 para 2005 ou 3.0 para 2008).

Uma vez feito o download, rode o arquivo de instalação do XNA. Ele fará
uma checagem para saber se você está com o Visual C# Express
instalado com o Service Pack mais atual.
Ao longo da instalação, pode ser que a apareça a janela do Firewall do
Windows. Não fique chateado, o Firewall só está fazendo o trabalho dele
de proteger o seu computador, e ele não tem como saber se o arquivo
que está rodando é um vírus, um cavalo de tróia ou o instalador do
XNA. Diga para ele que está tudo bem selecionando a opção “Yes, I wish
to select these rules to enable”, e marque as duas subopções. Pronto
agora o Firewall ficará mais tranqüilo.

Finalmente a o XNA Game Studio será instalado no seu computador.

Conceitos de programação de jogo no XNA

Para começar a entender o modelo de programação de jogos no XNA,

nada melhor do que começar criando uma solução de jogo XNA vazia e
remexer nos detalhes do código para entender os conceitos básicos por
trás do programa.

Abra o Visual C# e escolha File  New Project. Você verá caixa de

diálogo mostrada na figura 1. Neste diálogo, clique o tipo de projeto
Windows Game (2.0).

Figura 1. Criação de uma solução/projeto Windows Game (2.0)

Com o projeto criado, clique no ícone Start Debug (a setinha verde) na
barra de ferramentas. Embora não seja nada demais – apenas uma tela
azul – como você pode ver, esse programa já possui toda a base
necessária para começar a criar um jogo.

Feche o programa e analise os arquivos que foram criados por você. Na

seção Solution Explorer você pode ver os arquivos criados, como mostra
a figura 2.

Figura 2. Os arquivos criados pelo projeto na seção Solution Explorer

Juntamente com um ícone (.ico) e um arquivo de miniatura de imagem

(thumbnail), na figura 2 você pode ver que há dois arquivos de código
criados para você: Program.cs e Game1.cs. Para entender melhor o que
esses arquivos fazem, você precisa aprender um conceito básico de
programação de jogos: o loop de jogo.

Estrutura geral de um jogo

A lógica central para qualquer jogo inclui a preparação do ambiente

onde o jogo rodará, o processamento do jogo propriamente dito dentro
de um loop (laço de repetição), e a limpeza final do ambiente ao
término do jogo.

A idéia de ter o processamento principal do programa rodando dentro de

um loop é crucial para um jogo, porque o jogo precisa continuar
rodando esteja o usuário interagindo ou não. Isso não acontece com
outros tipos de aplicações, como aplicações comerciais por exemplo, nas
quais alguma coisa só é feita em resposta a entradas do usuário.

O pseudo-código a seguir apresenta uma estrutura simplificada de um

jogo, incluindo o loop do jogo:

Inicialize gráficos, entradas e sons

Carregue recursos (arquivos de imagens, modelos, etc)
Comece o loop do jogo. Para cada passo do loop:
Obtenha a entrada do usuário (caso haja alguma)
Realize o processamento necessário (IA, movimentos,
colisões, etc)
Se o critério do fim do jogo foi atingindo, se foi, pare
o jogo
Desenhe (renderize) a tela, gere sons e resposta de
jogo ao jogador
Fim Se
Fim Para
Finalize gráficos, entrada e sons
Libere recursos do sistema (memória, rede, etc)

Essa é uma visão simplificada – por exemplo, você pode carregar os

recursos dentro do loop do jogo, para cada nova fase. Mas ainda assim,
a idéia geral se mantém.

Antes do XNA, essa estrutura de jogo tinha que ser codificada do zero,
então você tinha que se preocupar com muitos detalhes que não
estavam diretamente relacionados com o jogo. O XNA esconde a maioria
dessas complexidades de você. Quando você cria um novo projeto
Window Game, os dois arquivos criados funcionam criando um objeto da
classe Microsoft.Xna.Framework.Game (o objeto Game1), apresentando
o código com os métodos significativos dessa classe que você precisa
sobrescrever, e chamando o método Run, que de fato inicia o jogo.

A seguir vamos apresentar os métodos do Game1 organizados na ordem

que o loop de jogo genérico que vimos os apresentou antes, então você
pode entender a estrutura geral de código antes de entrar em maiores
detalhes.

Game1()  método de inicialização do objeto Game1 (é o método

construtor). Encontra-se em Game1.cs.

Initialize()  método responsável pela inicialização do jogo. Encontra-se

no Game1.cs.
LoadContent()  é o método que carrega recursos gráficos. Encontra-se
no Game1.cs.

Run()  método que inicia o loop do jogo. Encontra-se no Program.cs.

Para cada passo:

Update()  método onde se lê a entrada do usuário, se realiza

processamentos e se testa se o critério de parada do jogo foi atingido.
Encontra-se no Game1.cs.

Draw()  é o método que contém o código de renderização das telas.

Encontra-se no Game1.cs.

UnloadContent()  dentro deste método fazemos a limpeza do

ambiente, liberando recursos gráficos e outros que tenhamos alocado
para execução do jogo. Encontra-se no Game1.cs.

Comparando o pseudo-código com os métodos expostos, você pode ver

que o tipo de projeto Windows Games provê uma estrutura de jogo
básico pronta, de forma que você pode começar a incluir o código
específico do seu jogo.

Se você abrir o arquivo Program.cs, você verá que há apenas poucas

linhas, como apresentado abaixo:

using System;

namespace WindowsGame2
{
static class Program
{
/// <summary>
/// The main entry point for the application.
/// </summary>
static void Main(string[] args)
{
using (Game1 game = new Game1())
{
game.Run();
}
}
}
}

Esse fragmento inclui a classe Program, onde você tem o ponto de

entrada da aplicação XNA – a função Main. Essa função possui duas
linhas: uma para criar o objeto de game a partir da classe Game1, e
outro para chamar o método Run desse objeto, o qual, como já
dissemos, inicia o loop do jogo.

Note que criando o objeto em uma instrução using, ele é

automaticamente liberado quando a instrução termina. Outro ponto a se
considerar é que o argumento args da função Main recebe parâmetros
de linha de comando usados quando o jogo é chamado. Se você incluir
argumentos de linha de comando em seu jogo – como um código
especial para ajudar você a testar o jogo – esse é o lugar onde você lida
com isso.

A classe Game1 é implementada no arquivo Game1.cs. Um olhada

rápida na classe Game1 nesse arquivo mostra que ela é derivada da
classe Microsoft.Xna.Framework.Game, a classe base oferecida pelo XNA
para encapsular a criação de janela, gráficos, áudio e inicialização de
entrada, e a lógica básica do jogo.

Inicialização do jogo

A classe Game1 começa por definir e criar objetos que referenciarão o

gerenciador de dispositivo gráfico, mais comumente conhecido no
mundo dos jogos como device, e um objeto SpriteBatch, usado para
desenhar um texto ou imagem 2D. O construtor da classe Game1
também configura o diretório raiz para o gerenciador de conteúdo, o que
é o ponto de entrada para o XNA Content Pipeline, então o Framework
XNA é informado onde encontrar o conteúdo do gráfico (gráficos, sons,
modelos 3D, fontes, e por aí vai). O pedaço de código a seguir
apresenta as inicializações do gerenciador de conteúdo e do device.

public class Game1: Microsoft.Xna.Framework.Game

{
GraphicsDeviceManager graphics;
SpriteBatch spriteBatch;

public Game1()
{
graphics = new GraphicsDeviceManager(this);
Content.RootDirectory = “Content”;
}
}
Você não precisa modificar essas primeiras linhas, ou incluir código
adicional aqui – você pode simplesmente usá-las como estão. Nas
próximas seções veremos detalhes sobre o device e o Content Pipeline,
então você poderá ter uma idéia geral do que está acontecendo por traz
das cenas.

O Gerenciador de Dispositivo Gráfico

O gerenciador de dispositivo gráfico, ou simplesmente device, é seu

ponto de entrada para a camada de manipulação de gráficos, e inclui
métodos, propriedades, e eventos que permitem que você consulte e
modifique essa camada. Em outras palavras, o device representa a
forma de gerenciar o acesso às características da placa gráfica.

Por agora, tudo que você precisa saber é que criando o objeto graphics
da classe GraphicsDeviceManager, uma janela de jogo é criada para
você, e você utilizará o objeto graphics quando realizar qualquer
operação gráfica. Todas as complexidades sobre consulta e inicialização
de características da camada gráfica 2D e 3D são transparentes para
você.

O Content Pipeline Manager

O Content Pipeline é uma das características mais interessantes que o

XNA traz para você, porque ele simplifica como seu jogo lida com o
conteúdo gerado por diferentes ferramentas geradoras de conteúdos.

Em um jogo não-XNA, você tem que se preocupar com como carregar o

conteúdo do jogo como áudio, gráficos, e modelos 3D: Onde o conteúdo
está localizado? Como seu programa irá ler esse conteúdo? Você possui
as bibliotecas certas para ler o conteúdo no formato que ele foi criado,
pela ferramenta comercial que o gerou?

O Content Pipeline arruma o processamento de todo o conteúdo do jogo

de forma que você pode lidar facilmente com ele. Ele é composto por
conjunto de passos, os quais incluem importadores para ler o conteúdo
e gerar um formato conhecido, um processador que lê esse formato, um
compilador de conteúdo que gera o conteúdo pronto-para-usar, e
finalmente o gerenciador de conteúdo. A figura 3 mostra o alto-nível do
Content Pipeline.
 .FBX
.X Importador
Processador
Gerenciador
Compilador de Conteúdo
.FBX Importador Content .FBX
de Conteúdo (tempo de
DOM
execução)
Processador
Importador
.TGA .FBX

Figura 3. O Content Pipeline do XNA

Uma coisa interessante sobre o Content Pipeline é que ele é baseado no

conteúdo que você efetivamente inclui em seu projeto C#. Isso significa
que quando o projeto é construído, o conteúdo é transformado para um
formato reconhecido e movido para um diretório predeterminado, então
o programa sempre será capaz de saber onde encontrar o conteúdo e
como utilizá-lo.

Quando se inclui conteúdo em um programa XNA, você usa um dos

importadores de conteúdo fornecidos como parte do framework. Esses
importadores normalizam os dados do conteúdo, colocando-os em um
formato que seja facilmente processado depois. Os importadores
suportam os seguintes formatos de arquivo:

• Formatos de arquivos 3D: X (usado pelo DirectX), FBX (formato

de arquivo de transporte, originalmente criado pela AutoDesk e
suportado pela maioria das ferramentas comerciais e muitas
ferramentas gratuitas)
 • Formatos de arquivos de material: FX (arquivos de efeitos, que
podem ser usados para descrever detalhes de renderização de
modelos 3D ou adicionar efeitos ao cenário 3D)

• Formatos de arquivos 2D: BMP, DDS, DIB, HDR, JPG, PFM, PNG,
PPM e TGA

• Descrição de fontes: SPRITEFONT (arquivos XML usados pelo XNA,

que descrevem como gerar o mapa de texturas a partir de um
tamanho de um tipo de fonte específica. O jogo então usa as
imagens do mapa de textura para escrever texto na tela)

• Formatos de arquivo de áudio: .XAP (gerado pela ferramenta

XACT, que importa a maioria dos formatos de arquivo de áudio)

Depois que os importadores processam o conteúdo, os processadores

irão ler esse conteúdo e gerar um objeto que o jogo possa manipular em
tempo de execução.

Finalmente, o jogo utiliza o gerenciador de conteúdo para ler os objetos

de forma que eles possam ser facilmente usados.

Você pode estender o compilador de conteúdo para incluir novos

processadores, e você pode também estender o Content Pipeline com
novos importadores, assim você não precisa utilizar necessariamente os
formatos predefinidos.

Métodos de inicialização do jogo em XNA

Olhando novamente para o pseudocódigo de lógica do jogo, você pode

ver que antes de entrar no loop do jogo, você tem realizar inicializações
necessárias e carregar recursos do jogo. Além do construtor da classe,
visto na seção anterior, em XNA algumas inicializações são feitas nos
métodos Initialize e LoadContents.

Por agora, tudo que você precisa saber é por que há duas rotinas de
inicialização; em momentos posteriores você verá em detalhes
exemplos para cada um destes métodos.

O método Initialize é chamado uma vez quando você executa o método

Run (descrito anteriormente), logo antes do loop do jogo começar. Esse
é o lugar certo para incluir qualquer rotina de inicialização não gráfica,
como, por exemplo, preparar o conteúdo de áudio.
Esse método também inclui uma chamada ao seu método base, que
visita os elementos da coleção GameComponents e chama o Initialize de
cada um deles. Isso significa que você pode gerar componentes que a
classe Game também irá chamar, quando você está criando jogos
sofisticados. Mas não se preocupe com esses detalhes agora: veremos
isso mais adiante.

Os gráficos são carregados em métodos separados porque às vezes o

jogo precisa recarregar os gráficos. Os gráficos são carregados de
acordo com as configurações atuais do device para dar o máximo de
desempenho. Então, quando essas modificações de configuração (como
quando você muda a resolução do jogo, ou quando você escolhe uma
janela em modo de tela cheia), você precisa recarregar os gráficos. O
método LoadContent é chamado toda vez que o jogo necessita carregar
ou recarregar os gráficos.

Finalização do Jogo

Antes de apresentar os métodos relacionados ao loop do jogo, daremos

uma rápida olhada nas rotinas de finalização do jogo.

Uma vez que as rotinas internas de finalização do XNA e o garbage

collector do XNA fazem a maior parte do trabalho de finalização para
você, a finalização é bem simplificada.

O projeto básico do jogo que você criou inclui uma sobrecarga para o
método UnloadContent. Esse é chamado toda vez que o jogo necessita
liberar algum recurso gráfico que você tenha carregado.

Jogos avançados podem incluir rotinas específicas em cada classe do

jogo para carregar e descarregar recursos gráficos, não necessitando do
uso desses métodos de carga e descarga.

Loop do Jogo

A maior parte do processamento do jogo ocorre dentro do loop do jogo.

É lá onde o jogo checa se há entradas do usuário para processar, a
inteligência artificial dos personagens do jogo é calculada, os
movimentos dos componentes do jogo são executados, as colisões entre
eles são consideradas, o critério de fim de jogo é testado, e finalmente,
onde o controlador de jogo é ativado, o som é tocado, e a tela é
renderizada.

A classe Microsoft.Xna.Framework.Game fornece dois métodos que

podem ser sobrescritos que o loop do jogo chama internamente:
Update, onde você deve incluir os cálculos do jogo, e Draw, onde você
renderiza os componentes do jogo. Vamos dar uma olhada mais de
perto nesses métodos, apresentados no próximo fragmento de código,
para sobressaltar detalhes relevantes:
protected override void Update(GameTime gameTime)
{
// Allows the game to exit
if (GamePad.GetState(PlayerIndex.One).Buttons.Back ==
ButtonState.Pressed)
this.Exit();
base.Update(gameTime);
}

protected override void Draw(GameTime gameTime)

{
graphics.GraphicsDevice.Clear(Color.CornflowerBlue);
base.Draw(gameTime);
}

O primeiro ponto importante a discutir é parâmetros gameTime recebido

por ambos os métodos. Esse parâmetro é crucial para toda a lógica do
jogo, porque o jogo precisa saber quanto tempo passou desde o último
passo do loop do jogo para realizar os cálculos corretamente – por
exemplo, para calcular a posição correta de um componente do jogo de
acordo com sua velocidade no jogo. Vejamos com mais detalhes as
propriedades da classe GameTime:

• ElapsedGameTime: Esse propriedade representa a quantidade de

tempo do jogo desde a última vez que o loop do jogo foi chamado.
Lidar com o tempo do jogo significa que o loop do jogo é chamado
um número fixo de vezes por segundo, então a lógica do jogo
pode usar o tempo do jogo como uma unidade de base de tempo
para realizar cálculos. Criar jogos baseados em tempo de jogo ao
invés de tempo real é mais fácil, basta incrementar os
componentes do jogo pelo intervalo calculado em cada
atualização. Quando a propriedade IsFixedTimeStep da classe
Game é true, essa classe garante que o método Update será
chamado o número certo de vezes por segundo, ignorando
quadros em um jogo lento se for necessário.
 • ElapsedRealTime: Essa propriedade representa a quantidade de
tempo real desde a última vez que o loop de jogo foi chamado. Ao
definir a propriedade da classe Game, IsFixedTimeStep para false,
o loop do jogo irá rodar na velocidade máxima, sendo chamado
tantas vezes por segundo quantas forem possível. Isso pode
aumentar a complexidade de programação do jogo, mas também
pode permitir um aumento grande na velocidade do jogo.

• TotalGameTime e TotalRealTime: Essas propriedades representam

o total de tempo desde que o jogo iniciou, contado em tempo de
jogo (fixado em unidades por segundo) ou tempo real.

• IsRunningSlowly: Se a classe Game estiver chamando o método

Update menos do que o definido na propriedade
Game.TargetElapsedTime, essa propriedade é definida como true,
então o jogo possui a informação para fazer algum ajuste
necessário.

Outro detalhe que merece ser mencionado sobre o método Update é que
ele vem com um código predefinido para terminar o jogo quando o
botão Back é pressionado no controlador do Xbox 360:

if (GamePad.GetState(PlayerIndex.One).Buttons.Back ==
ButtonState.Pressed)
this.Exit();

A classe GamePad permite acessar o estado corrente do controlador e

habilita o jogo a disparar a vibração do controle. A classe não armazena
a entrada do usuário, então a informação que você pega é sincronizada
exatamente com interação corrente do usuário. Como você pode inferir
pelo código anterior, você pode checar o estado de botões, gatilhos,
thumbsticks, ou controles direcionais.

Falaremos sobre a manipulação da entrada do usuário em outra

oportunidade, incluindo gamepad, mouse e teclado.

O método Draw inclui uma linha para limpar o dispositivo gráfico,

preenchendo a janela com uma única cor – CornflowerBlue;

graphics.GraphicsDevice.Clear(Color.CornflowerBlue);

Como foi dito anteriormente, o device (representado aqui pela variável

graphics) é sua interface com a camada de gráficos e será usada em
todas as operações gráficas. Nesse caso, o código mostra o uso da
propriedade GraphicsDevice, que expõe propriedade e métodos que
permitem a leitura e definição de muitos detalhes sobre a renderização
do jogo. Nós não vamos muito fundo nessa classe por enquanto; você
vai aprender mais em artigos posteriores.
Distribuindo seu jogo XNA para outros PCs

Imagine que você terminou a primeira versão seu jogo e gostaria de

mostrá-lo para seus amigos em seus computadores. Você sabe que
pode procurar pelo executável (arquivo com o jogo compilado) na pasta
do projeto. Dentro da pasta do projeto você segue o caminho
“bin\x86\Debug\” e encontrará o executável do jogo.

Porém, quando você coloca esse arquivo no computador de um de seus

amigos e dá duplo-clique ao invés da sensação de mostrar o seu jogo
você tem a frustração de ver erros pularem na tela.

Distribuir um jogo XNA para outros PCs ainda é uma das tarefas que
requer mais atenção do time de desenvolvedores. Para que tudo dê
certo, você tem que instalar três pacotes separados, na máquina que
rodará o jogo, antes de você sentir-se seguro para rodar o executável
do jogo.

Os três pacotes são:

• O XNA Framework Redistributable 2.0

• O DotNet 2.0 Framework Service Pack 1

• Os arquivos DirectX 9.0c Runtime

Além disso, no caso do seu jogo possuir funcionalidades de acesso a

rede, você terá que instalar o pacote do XNA Game Studio 2.0 completo
no PC de destino.

Os erros citados no início dessa seção ocorrem porque o executável

assume que alguns arquivos básicos do XNA já estão instalados no
sistema. Eles estão de fato no seu computador, uma vez que você
tem instalado o XNA Game Studio. Mas no computador de outras
pessoas isso não é garantido. Portanto, se o seu jogo não conseguir
detectar os arquivos no sistema, você obterá... erros.