CubaGames

O PS Move Dará A Volta Por Cima

Fernando Lorenzon — Wed, 28 Jul 2010 15:22:57 +0000

Dos 4 controles de movimento (Wiimote, Kinetic, Sixaxis, Move), os dois pertencentes à Sony eram visivelmente os piores.

O Sixaxis nunca foi levado tão á sério mesmo, e até foi odiado por alguns porque teria sido o motivo de tirarem a função rumble dos primeiros controllers do PS3.

Da nova geração de sensores, ficava cada vez mais claro que o Move era somente uma solução feita às pressas para não ficarem tão mal na fita nas E3 da vida.

Mas estávamos errados!

Quanto mais eu leio e vejo sobre o Move, mais me impressiono. É óbvio que o Kinetic (projeto Natal) é mais chamativo, mas nunca me empolguei muito com a tecnologia. Coisas futuristas demais não funcionam (cof cof Power Glove cof…).

Mas o que tem o Move de especial? Para mim, o mais importante: aprimoramento. Ele pega tudo o que o Wii Remote tem de bom e melhora ainda mais. Uma das reclamações com relação ao sensor da Nintendo era de que havia um pequeno lag e pouca capacidade de reconhecimento dos movimentos. Eles até melhoraram isso com o Motion Plus. Aí a Microsoft anuncia o Natal, e o que lemos por aí são reclamações sobre um possível lag, além de limitações para reconhecimento de movimentos mais sutis. Até aí, parece ok. Mas se um controller propõe ler os movimentos, não adianta vir com a próxima geração e continuar com os probleminhas iniciais.

A Sony está realmente dando um basta nisso com o Move, melhorando o conceito do Wii sem criar outros problemas.

Acabei de ler no Pop que consideram o Move tão preciso quanto simuladores de cirurgia!

E aquela bolinha que acende? “Quanta besteria”, imaginei. Aí, quando a Sony disse que poderia reproduzir qualquer cor, e que poderia ser utilizado para representar, por exemplo, clarões de tiros, fiquei maluco.

Estou mesmo empolgado com o Move, mas certamente vai demorar muito para eu experimentá-lo. Pelo menos, ele NÃO me parece ser chamariz para o público casual. PS Move para mim passou a soar como coisa séria!

PS.: Há uma declaração em que Shigeru Miyamoto lamenta que o Kinetic e o Move são cópias do Wii. O mérito da inovação ainda continua com a Nintendo, mestre. Mas não foi a Nintendo aquela empresa que começou no ramo de games copiando games e arcades americanos famosos e lançando-os no Japão?

Pensamento do Dia – LEGO Starcraft

Fernando Lorenzon — Tue, 27 Jul 2010 19:15:22 +0000

Estava aqui no trabalho discutindo com meus amigos sobre Starcraft II (lançamento hoje!), e quando um comenta sobre o cancelado Starcraft Ghost, eu tive uma excelente idéia!

Por que não fazer games de Starcraft baseados cada game numa unidade do jogo?

Tipo, teríamos o Starcraft Ghost (com os ghosts); Starcraft Marine, de tiroteio em terceira pessoa; Starcraft Tank (destruindo tudo com os tanques), e por aí vai.

E o melhor de tudo, seria baseado na série LEGO, estilo LEGO Star Wars!

Perfeito! Vamos esperar a Blizzard descobrir isso, ou alguém fazer um mod…

Links Bacanas, Ou Não

Fernando Lorenzon — Tue, 27 Jul 2010 02:03:48 +0000

Gostaria de compartilhar com vocês um pouco do que eu leio na Internet com alguma frequência. Depois de algum tempo escrevendo no blog, alguns podem querer saber quais são meus sites preferidos, e com isso ter uma idéia de quais assuntos eu me interesso.

Enfim, vejam os sites e blogs que costumo acessar com certa frequência, devidamente categorizados:

Política:
Reinaldo Azevedo
Sustentável é Pouco – Dennis Russo

Notícias/Atualidades
Veja On-Line
Meio Bit

Games:
Gamespot
Meio Bit Games
Continue
Gagá Games

Ciência/Ceticismo:
Bad Astronomy
Projeto Ockham
Ceticismo Aberto

Podcasts
Jovem Nerd
Fronteiras da Ciência
Audiogame (R.I.P.)

Games (Video)
Gametrailers
Screw Attack
Angry Videogame Nerd

Jogo Livro Não. Jogo Revista Sim

Fernando Lorenzon — Wed, 21 Jul 2010 16:24:16 +0000

Lendo alguns blogs por aí, me deparo com discussões sobre o caso perdido dos jRPGs. Muita gente reclamando da linearidade, e outros justificando-a.

Uma dessas discussões ocorreram no Meio Bits Games, num post questionando o caminho que Final Fantasy deve seguir.

Eu escrevi alguns comentários e tal, e muito do que escrevi vem me incomodando há muito tempo. E parece ser algo universal mesmo, visto que esses posts levantam muitas discussões.

O que indaguei é que Final Fantasy se parece demais com um livro. Um livro de ficção possui uma história linear, que deve ser lida de maneira linear, sempre no mesmo sentido, avançando no ato de virar as páginas. Pois um game como Final Fantasy, a história é sempre pré-estabelecida, correndo sempre num mesmo sentido, e sendo passada conforme completamos quests.

Ou seja, trata-se de uma estrutura muito similar a de um livro.

Para um livro, não há nada de ruim. Mas para um game, seguir um caminho pré-estabelecido tira muito da diversão que teríamos caso a exploração e experimentação fossem mais valorizadas.

Em se tratando de um RPG, considero uma estrutura linear como algo altamente falho. Mas não quer dizer também que defendo um mundo todo aberto e com infinitas possibilidades. Para constar, Fallout não me agrada tanto também.

O que eu gostaria de ver mais nos RPGs em geral é o bom e velho meio-termo. Aristóteles, meu filósofo favorito, já dizia que a virtude é o justo meio entre dois extremos. Portanto, não estou defendendo um mundo todo acessível, mas uma pequena quebra na estrutura rígida dos RPGs japoneses.

A decisão de quebrar esta linearidade deve ser difícil de tomar por que sem a estrutura de livro, fica muito difícil construir uma boa narrativa. Metal Gear depende totalmente disso para funcionar como o “filme” que muitos adoram. Mas quando o propósito principal de um game é contar uma história, não estamos errando de mídia? Por que não fazer logo um FILME do Metal Gear?

Enfim, a abordagem que considero ser mais apropriada num game é a da revista. Um game-revista. Diferente do game-livro, o game-revista pode ser saboreado em partes menores, em uma ordem menos linear, com pedaços independentes que juntos adicionam ao produto final, mas que separados também funcionam muito bem.

Um game deve ser linear o suficiente para não ficar maluco e desconexo, mas deve dar ao jogador sempre que possível o gostinho de explorar e principalmente de BRINCAR com ele. Sei que muitos não se importam com isso, mas vamos deixar o fanatismo de lado. RPG nunca pode se firmar somente na história. Diverte muito também a parte de criar o personagem. De explorar livremente o mundo. Jogar sem ter a pressão de ir para um lugar imediatamente.

Logicamente, RPGs japoneses nunca foram muito além disso. Mas isso não é desculpa para continuar assim. Mario está aí, evoluindo a cada novo game. Defender FF dizendo que os anteriores sempre foram lineares seria o equivalente de criticar os novos gráficos em 3D porque os antigos sempre foram em 2D.

Games-Revista já!

Por Que Estou Ansioso por Dragon Quest IX

Fernando Lorenzon — Fri, 16 Jul 2010 16:39:51 +0000

Dragon Quest nunca foi tão aclamado fora do Japão. Numa época onde Final Fantasy virou jogo sério com personagens emos, Dragon Quest segue firme com seu estilo de desenho animado. Mesmo assim, a série nunca me conquistou. Não havia nada ali que superasse outros RPGs. Não havia nem mesmo alguma novidade a cada nova versão.

Mas agora, justamente na versão menos ambiciosa, o jogo veio com muitas coisas que me deixaram curioso. Olha só que legal, em Dragon Quest IX, você pode criar seu próprio personagem. Isso é algo que sempre desejei ver nos RPGs em geral. Afinal, RPG é principalmente sobre criar personagens, uai! E as batalhas são por turno, mas não são aleatórias (finalmente…). Os encontros seguem mais ou menos o estilo de Chrono Trigger.

E por falar em Chrono, acho a arte de Akira Toriyama muito mais interessante para este estilo de jogo que a abordagem angelical da Square.

É possível escolher a classe do personagem. É possível criar armas e itens em geral. Enfim, muito do que eu gostaria de ver em um RPG está presente aqui, com algumas limitações, mas pelo menos estão aqui.

Como não possuo DS e nem pretendo adquirir um, só poderei experimentar o game via emulador. Agora que a versão americana foi lançada, meterei as mãos no game e vou avaliar melhor. Pena que o emulador ainda não possui boa performance.

(Agora vem meu momento de reflexão)

Não digo que Dragon Quest seja o melhor RPG que existe, mas FINALMENTE resolveram fazer algo diferente na jogabilidade dele. O pior é que nenhuma das novidades são realmente “novas”. Tudo já foi em algum momento utilizado em RPGs anteriores:

- Trocar de classe já foi amplamente explorado no ocidentalmente desconhecido Final Fantasy V.

- Batalhas não aleatórias foram usadas em Chrono Trigger.

- Criar personagens já virou moda. Vide os Miis e outros avatares dos outros consoles.

- Grande número de quests secundárias é um padrão dos RPGs americanos.

Aparentemente esta nona versão da série vai provar que o gênero de RPG japonês ainda pode fazer sucesso. No Japão o game foi sucesso absoluto. Mas por que não incluíram todas essas novidades nas versões anteriores?

Porra, os japas reclamam que a indústria japonesa está em declínio, mas não fazem nada de diferente para reverter a situação. Quando foi que um RPG te conquistou por ter algo de diferente e interessante? Eu ainda considero Chrono Trigger muito superior em sua jogabilidade que os RPGs mais novos. Não há absolutamente nenhuma mudança significativa na jogabilidade dos novos games do gênero a ponto de chamar minha atenção.

Japoneses, todas as fórmulas para fazer um bom game já foram testadas e aprovadas. Muitas delas inventadas por vocês há mais de uma década.

Que tal começar a utilizá-las?

Dragon Quest IX é um pequeno passo. Vamos ver se a moda pega.

E antes que digam que Final Fantasy XIII foi uma grande evolução, já vou adiantando que mudar os mecanismos da batalha e melhorar os gráficos não é o suficiente para alguém não-fã se interessar pelo game.

Criando Um Jogo em XNA – Parte 7 – Conclusão

Fernando Lorenzon — Sun, 11 Jul 2010 22:53:24 +0000

Finalmente chegamos ao final desta série. Obviamente eu não cobri tudo sobre XNA, mas também não era o foco inicial dos posts. A idéia era dar uma pincelada sobre o básico deste framework. No futuro, conforme eu for descobrindo coisas mais legais, eu vou escrevendo mais. Estou atualmente estudando conceitos de games de corrida e criação de tile-maps (bloquinhos para criar fases).

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

Criando Um Jogo em XNA – Parte 6 – Audio

Fernando Lorenzon — Mon, 05 Jul 2010 13:34:37 +0000

Continuando a série sobre XNA, vamos abordar o áudio do XNA.

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:

PLAIN TEXT

Song song = Content.Load<Song>("Songs\\Intro");

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

PLAIN TEXT

MediaPlayer.IsRepeating = true;
MediaPlayer.Play(song);
MediaPlayer.Stop();

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.

PLAIN TEXT

SoundEffect SFXExplosion = Content.Load<SoundEffect>("Sounds\\explosion");

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

PLAIN TEXT

SFXExplosion.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:

PLAIN TEXT

SoundEffect SFXRocket = Content.Load<SoundEffect>("Sounds\\rocket");
SoundEffectInstance SFXRocketInstance = Globals.SFXRocket.CreateInstance();

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:

PLAIN TEXT

SFXRocketInstance.Play();

Parte 5 - Mais Scenes
Parte 7 - Conclusão

Clássico – The King of Fighters ’96

Fernando Lorenzon — Fri, 18 Jun 2010 16:47:57 +0000

The King of Fighters é amplamente conhecido por todos aqueles esquisitos que frequentam os fliperamas. Mas como eu cresci numa galáxia distante, meu primeiro contato com a série foi num Playstation. E a versão foi justamente The King of fighters '96. Por uma questão de nostalgia, ou por pura qualidade mesmo, esta foi por muito tempo minha versão preferida da série.

Uma das coisas que mais se destaca é a trilha sonora, a melhor da série. Mas não só isso, pois KOF '96 implementou grandes melhorias no sistema de combate com relação às suas versões anteriores. Na época, poucos jogos de luta eram tão profundos.

Em alguns textos antigos eu defendi a série KOF como bons jogos de luta, principalmente por causa do carisma dos personagens. Na época, os jogos do gênero eram geralmente populados por monstros ou lutadores bizarros. Como identificar-se com um lobo de Killer Instinct ou com um demônio em Motal Kombat? Menos grave, mas digno de lembrança: como gostar de controlar um karateka sujo e descalço ou um magricelo faquir-style de fraudas em Street Fighter? Sei que não é tão grave, mas encontrar pessoas normais, com vidas relativamente normais, empregados e/ou estudando ajudava o jogador a entrar no clima.

Em Street Fighter, personagens de diferentes personalidades usam exatamente a mesma roupa, como é o caso de Ryu e Ken. Em KOF, Ryo usa kimono, por ser um aluno dedicado, e Robert usa roupas de grife, camisa aberta, calça social e sapatos, mostrando sua personalidade de playboy. Enquanto Ken se parece com He-Man, Robert lembra Antonio Bandeiras ou Steven Seagal (seria isso uma vantagem?).

Os estilos de luta dos personagens da série são muito legais e muito superior ao Street Fighter. COMO?!?!?! Muitos podem indagar. Se analisarmos o estilo de luta de cada lutador de Street Fighter, notamos muitas similaridades nos golpes. Quase todos os lutadores possuem um projétil que atravessa a tela e não abre muita brecha na vulnerabilidade; um golpe anti-aéreo; um golpe multi-hit. Já em KOF temos lutadores com golpes variados, sendo muitos deles únicos em seu delay, força e alcance.

Assistir uma luta entre Ryu e Akuma resume-se a chuvas de hadoukens enquanto shoryukens intercepta pulos.

Já em KOF, vemos golpes sendo usados com mais cautela, pois o tempo de vulnerabilidade é maior. Mesmo lutadores com estilos de luta parecidos acabam lutando de maneiras diferentes. Goro Daimon e Clark lutam usando arremessos e tombos (o primeiro luta Judô e o outro Jiu-Jitsu). Mas Goro luta aguardando ataques, mais na defensiva, enquanto Clark usa dashs e corre na direção do inimigo para pegá-lo desprevenido.

Em Street Fighter, a falta de corridas e esquivas faz todos usarem as apelativas fireballs constantemente do canto da tela. KOF força o jogador a se aproximar ou contra-atacar mais vezes.

Ainda no campo dos lutadores, KOF sempre se destacou pela quantidade absurda de lutadores distintos. Eu contei e me surpreendi. São 29 lutadores! E 29 lutadores com estilo de luta únicos, e não clones com os mesmos padrões de movimento como em Street Fighter e Mortal Kombat.

(Ai ai, como gosto de bater em Street Fighter... Mas gosto muito de Ryu & Cia também)

A história segue a saga Orochi. Kyo e Iori são descendentes de clãs que selaram o demônio Orochi há 1800 anos atrás. Rugal começa a busca pelo selo e assim liberar todo o poder de Orochi para uso próprio. Ele não consegue e morre definitivamente em KOF '95. Agora, um dos seguidores de Orochi tenta novamente abrir o selo e tenta impedir que os heróis o selem novamente. Este guerreiro chama-se Goenitz e tem o poder de controlar o vento. Tendo Kyo o poder do fogo, Goro o poder da terra e Chizuru o poder do coração, eles buscam Aquaman com o poder da água para então invocarem o Capitão Planeta... ou algo parecido.

Na história do jogo, Kyo e Iori são rivais e volta e meia se pegam numa porradaria para ver quem é mais emo. Passei boa parte da minha adolescência jogando KOF com meus amigos. Eu sempre preferi jogar com Kyo, enquanto alguns jogavam com Iori. Logo, era comum os dois se encontrarem em combate. Fazíamos questão de deixar esses dois por último na ordem do time para encerrar a batalha. Com isso, combates entre Kyo e Iori ocorriam com frequência, dando à disputa mais rivalidade e profundidade. Por falar em rivalidades, é uma tradição em KOF alguns personagens fazerem entradas diferentes dependendo do adversário. Geralmente eles interagem entre si, saudando-se ou mostrando raiva. Kyo e Iori trocam algumas falas, enquanto Terry contra Geese mostra o punho e grita "Geeeeeese!":

Os gráficos não são tão bons assim. Mas o nível de detalhes dos cenários é doentio:

KOF '96 talvez tenha os cenários mais interessantes da série. Os sons são meio ruins também, assim como a dublagem que é às vezes inexpressiva e a baixa definição do áudio deixa as vozes roucas. Em KOF '97 os sons já melhoraram bastante.

Se fosse eleger um dos jogos da série como o melhor sistema de luta, eu escolheria o '99 (mas sem strikers). Mas no geral, ainda considero KOF '96 o grande game da série. Sua trilha sonora está viva em minha memória e faz parte da minha vida. Claro que na versão arranged. KOF '96 marca o início da era de ouro da SNK, com seus jogos marcados pelos controles excelentes, músicas intensas e artworks altamente detalhados, realistas, fugindo do estilo animê que predominou posteriormente.

Criando Um Jogo em XNA – Parte 5 – Mais Scenes

Fernando Lorenzon — Fri, 11 Jun 2010 16:17:18 +0000

Continuando a explicar o conceito de Scenes, vimos como o Game1 trabalha com as scenes. Vamos agora ver como é a implementação dentro da Scene.

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:

PLAIN TEXT

public abstract class Scene
{
public List SpriteList;
public List FontList;
public Color BackgroundColor;
public Scene()
{
Classes.Globals.MustLoadContent = true;
this.BackgroundColor = Color.Black;
this.SpriteList = new List();
this.FontList = new List();
}
public virtual void LoadScene()
{
this.LoadSpriteList();
this.LoadFontList();
}
public virtual void UnloadScene()
{
this.SpriteList = null;
this.FontList = null;
}
public virtual void LoadSpriteList()
{
}
public virtual void LoadFontList()
{
}
public virtual void Update()
{
}
}

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:

PLAIN TEXT

protected override void Update(GameTime gameTime)
{
Globals.CurrentScene.Update();
base.Update(gameTime);
if (Globals.MustLoadContent)
{
this.LoadContent();
}
else
{
this.Draw(gameTime);
}
}

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:

PLAIN TEXT

public class SceneTitle : Scene
{
private Sprite titleScreen;
private Sprite cursor;
private Font title;
private Font arcade;
private Font freeGame;
private Font oreCollecting;
private Font chooseShip;
private Font currentShip;
private Font exit;
public SceneTitle() : base()
{
}
public override void LoadScene()
{
base.LoadScene();
Globals.SelectedShip.X = this.currentShip.Position.X + 70;
Globals.SelectedShip.Y = this.currentShip.Position.Y - 5;
Globals.FontInfo1.Text = "Pressione Enter para selecionar";
this.gameOptions = Enum.Options.Arcade;
}
public override void LoadSpriteList()
{
this.titleScreen = new Sprite(800, 450, "Images\\Menu\\LunarLander");
this.cursor = new Sprite(16, 16, "Images\\Misc\\VMenuCursor");
this.cursor.Y = 550;
this.SpriteList = new System.Collections.Generic.List<Sprite>();
this.SpriteList.Add(this.titleScreen);
this.SpriteList.Add(this.cursor);
this.SpriteList.Add(Globals.SelectedShip);
}
public override void LoadFontList()
{
this.title = new Font("Fonts\\Title", "XNA Lander", new Vector2(270, 22), Color.Lime);
this.arcade = new Font("Fonts\\MenuOptions", "Arcade", new Vector2(10, 533), Color.Lime);
this.freeGame = new Font("Fonts\\MenuOptions", "Jogo Livre", new Vector2(75, 533), Color.Lime);
this.oreCollecting = new Font("Fonts\\MenuOptions", "Coletar Minério", new Vector2(160, 533), Color.Lime);
this.chooseShip = new Font("Fonts\\MenuOptions", "Escolher Nave", new Vector2(275, 533), Color.Lime);
this.exit = new Font("Fonts\\MenuOptions", "Sair", new Vector2(380, 533), Color.Lime);
this.currentShip = new Font("Fonts\\MenuOptions", "Nave Atual", new Vector2(600, 533), Color.Lime);
this.FontList = new System.Collections.Generic.List<Font>();
this.FontList.Add(this.title);
this.FontList.Add(this.arcade);
this.FontList.Add(this.freeGame);
this.FontList.Add(this.oreCollecting);
this.FontList.Add(this.chooseShip);
this.FontList.Add(this.currentShip);
this.FontList.Add(this.exit);
this.FontList.Add(Globals.FontInfo1);
}
public override void Update()
{
Functions.KeyReading();
if (Globals.EnterKeyPressed)
{
//entra na opção selecionada
}
if (Classes.Globals.RightKeyPressed)
{
//move o cursor para a direita
}
else if (Classes.Globals.LeftKeyPressed)
{
//move o cursor para a esquerda
}
}

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

Criando Um Jogo em XNA – Parte 4 – Scenes

Fernando Lorenzon — Mon, 07 Jun 2010 16:10:43 +0000

Nesta parte 4, vamos falar de Scenes.

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:

PLAIN TEXT

protected override void Initialize()
{
this.IsFixedTimeStep = true;
this.graphics.PreferredBackBufferWidth = 800;
this.graphics.PreferredBackBufferHeight = 600;
this.spriteBatch = new SpriteBatch(this.GraphicsDevice);
FunctionsGame.LoadGame();
Globals.CurrentScene = new SceneTitle();
base.Initialize();
}

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():

PLAIN TEXT

protected override void LoadContent()
{
Globals.CurrentScene.LoadScene();
foreach (Classes.Sprite sprite in Globals.CurrentScene.SpriteList)
{
sprite.Texture = Content.Load<Texture2D>(sprite.TexturesPath);
}
foreach (Classes.Font font in Globals.CurrentScene.FontList)
{
font.SpriteFont = Content.Load<SpriteFont>(font.SpriteFontPath);
}
Globals.MustLoadContent = false;
}

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():

PLAIN TEXT

protected override void Update(GameTime gameTime)
{
Globals.CurrentScene.Update();
base.Update(gameTime);
if (Globals.MustLoadContent)
{
this.LoadContent();
}
else
{
this.Draw(gameTime);
}
}

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:

PLAIN TEXT

protected override void Draw(GameTime gameTime)
{
this.GraphicsDevice.Clear(Globals.CurrentScene.BackgroundColor);
spriteBatch.Begin(SpriteBlendMode.AlphaBlend, SpriteSortMode.Immediate, SaveStateMode.SaveState);
foreach (Sprite sprite in Globals.CurrentScene.SpriteList)
{
if (sprite.Visible)
{
spriteBatch.Draw(sprite.TextureCurrent, sprite.Rectangle, sprite.Color);
}
}
spriteBatch.End();
spriteBatch.Begin(SpriteBlendMode.AlphaBlend, SpriteSortMode.FrontToBack, SaveStateMode.SaveState);
foreach (Font font in Globals.CurrentScene.FontList)
{
if (font.Visible)
{
spriteBatch.DrawString(font.SpriteFont, font.Text, font.Position, font.Color);
}
}
spriteBatch.End();
base.Draw(gameTime);
}

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