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?

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…

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

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á!

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.

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

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:

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

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.

Continue lendo este artigo »

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:
Continue lendo este artigo »

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:

Continue lendo este artigo »