Mini-Reviews: Zone of the Enders HD Collection (Xbox 360)

Análises com um máximo de 1.000 caracteres para você ler enquanto toma um café

Essa coletânea traz dois ótimos “shooters de arena”, nos quais você pilota um robô gigante com total liberdade de movimentos, só que em ambientes controlados. Ambos foram lançados originalmente para o PlayStation 2.

O primeiro ZOE é quase uma prova de conceito: as mecânicas de navegação e combate foram plenamente desenvolvidas e os gráficos eram magníficos para a época, mas há poucas fases e falta criatividade no level design. Ainda assim, os combates são tão ágeis e divertidos que o jogo acaba valendo a pena.

Mas o quente da coletânea é mesmo ZOE2. Os combates ficaram ainda melhores, com a possibilidade de lançar múltiplos disparos teleguiados contra nuvens de inimigos ao melhor estilo Panzer Dragoon. As fases são bem mais variadas, com ambientes que exigem novas estratégias. Dá até para arrancar partes do cenário para lançar contra os inimigos.

A coletânea é altamente recomendada tanto para fãs de robôs japoneses quanto para fãs de shooters.


TheBoss 012 – Gears Of War: Judgment

O quarto Gears Of War foi lançado com a toda-poderosa Unreal Engine no final da carreira do Xbox 360. Neste título, o cover mais eficiente da indústria — molde para a mecânica de metade dos jogos de ação em terceira pessoa com tiroteio dos últimos anos — é apresentado em toda sua glória.

Sob o olhar de um novato na franquia que imaginava este jogo como um “FPS em terceira pessoa”, convido-os a assistirem nosso review do Gears Of War: Judgment repleto de referências relevantes e irrelevantes…

TheBoss 012

Gears Of War: Judgment

 


Torion 2 (PC)

Por Euler Vicente

O amigo que acompanha o Cosmic Effect lembra que, no post sobre Zanac, citei um jogo que havia desenvolvido em homenagem ao meu game de nave favorito. Acredito que algumas pessoas ficaram curiosas em conhecê-lo, saber como se deu o processo de desenvolvimento, minhas dificuldades e inspirações. Como Torion 2 é 100% retrô, acredito que possa render uma curiosa leitura para os nossos amigos. Afinal de contas, quem joga videogame sempre teve vontade de fazer seu próprio jogo, não é mesmo?

Quer saber como funciona um shooter 2D? Então, continue conosco!

Como tudo começou: o campeonato da UniDev!

Sempre tive como um hobby pessoal a programação de computadores. Desde o MSX, já codificava algumas coisas simples. Obviamente, como nesta época programava para me divertir (sim, isso é possível!), não me interessava em aprender a fazer aplicações sérias; só queria saber de fazer jogos, gráficos legais. À medida em que o conhecimento técnico foi progredindo, o sonho de fazer um shooter como Zanac tornava-se cada vez mais factível.

Até que um dia, um site brasileiro muito legal de desenvolvimento de jogos, o UniDev – Programação de Jogos, lançou um concurso para os leitores, em 2003. A proposta era de apresentar um projeto de um jogo (ou demo) dentro de de 6 meses. Não lembro qual era o prêmio, ou mesmo se era relevante para mim: só sei que aquilo havia me deixado animado a seguir em frente. Tinha chegado o momento de produzir o meu Zanac!

Lembro que os projetos iam surgindo em profusão no site, diversos bem mirabolantes (risos). Um beat’em up à la Streets of Rage; tinha até uma turma que pretendia desenvolver um RPG cheio de detalhes. pensava com meus botões: esses caras vão conseguir realmente fazer isso tudo em 6 meses?

Pelo prazo proposto pelo site, não quis me arriscar a começar algo que não conseguiria terminar. Pela experiência que já obtive através do desenvolvimento de dois outros jogos autorais menores (Torion e Meteoros), acreditava que jogos de nave seriam mais fáceis de produzir: não precisamos nos preocupar com física, as colisões são mais simples… e era o gênero que eu mais gostava!

Então, inscrição no site realizada e mãos à obra, Euler!

Hello World!

Minha base de programação sempre foi a linguagem Visual Basic. Foi a ferramenta que me acompanhou durante boa parte da minha vida profissional e, com o tempo, fiquei bem experiente na dita-cuja (fiz 90% na prova de certificação da Microsoft). Meu contato inicial com o DirectX foi, inclusive, através do próprio VB.

Observem que, em tese, qualquer jogo pode ser produzido em Visual Basic pois, na realidade, quem renderiza os gráficos, efeitos sonoros e entrada de dados é a extensão DirectX, não a linguagem de programação. Ela somente representa a interface para acessarmos a API do DirectX – precisa apenas fornecer suporte para tal. Por exemplo, já vi ótimos projetos em Delphi – outra linguagem “atípica” no desenvolvimento de games – para dar uma idéia para vocês.

Porém, eu andava entediado com o VB. Não seria uma boa oportunidade para aprender outra linguagem de programação? Que tal C++ para arrebentar de vez? Não é ela a tal linguagem de programação usada nos projetos profissionais? Decidi encarar o desafio.

É importante ressaltar que, apesar de boa parte do jogo ser de responsabilidade do DirectX, a lógica de programação, cálculos matemáticos e iterações (os loops) são confeccionadas na linguagem de programação. E, neste aspecto, o C++ faz toda a diferença do mundo. É muito mais rápido do que o VB, Java ou o Delphi. Por isso a predileção do C++ em situações mais profissionais. Eles poderiam fazer um Half-Life 2 em Visual Basic, mas ficaria tão lento…

O que me trouxe bastante confiança em começar meu projeto numa linguagem de programação que nunca tinha visto na vida foi um engine que havia encontrado: o CDX. Gratuita, com o código fonte disponível, lotada de exemplos práticos e altamente didáticos. Com um pouco de estudo, pude assimilar sem maiores dificuldades.

E, então, iniciei meu primeiro programa em C++. Normalmente quando começamos a aprender uma nova linguagem de programação, fazemos um programinha bem simples que imprime na tela os dizeres: “Hello World!”. Isso é uma espécie de tradição no mundo da informática. No meu caso, meu “Hello World!” foi logo Torion 2! (risos)

Gráficos & trilha sonora: quem aí pode me ajudar com isso?

Uma coisa que aprendi: jogos são projetos multi-disciplinares. Não é possível somente um indivíduo cuidar de tudo. Até mesmo porque as pessoas são diferentes, têm aptidões diferentes e, no meu caso, definitivamente não levo jeito para a parte artística da coisa.

A tal questão artística representava um grande limitador ao projeto. Por vezes, tinha uma boa idéia, sabia como implementá-la tecnicamente falando, mas… do que adiante se não tinha os sprites corretos? A coisa foi tão séria para mim no começo que o projeto foi tomando outro rumo: normalmente se planeja o gameplay, são esboçados os cenários e personagens e, somente depois, a equipe artística realiza o que foi imaginado. Em Torion 2 foi ao contrário! (risos) Fuçava sprites na Internet, efeitos sonoros, músicas, até achar algo que pudesse aproveitar. Daí, desenvolvia o gameplay em cima dos recursos artísticos encontrados. Acham que queria colocar aquela arma do bumerangue do Knightmare no jogo? Eu tive de aproveitá-la, pois o sprite estava lá disponível, todo arrumadinho esperando que eu pensasse em algo… (mais risos)

Para terem uma idéia do meu desespero, a nave Torion foi produzida a partir de um mesh (modelo 3D) feito para o 3D Studio. Baixei o modelo de um daqueles sites especializados em 3D Studio, abri o software e renderizei em 2D a nave vista de cima. Depois, inclinei-a para a direita e tirei outra foto. Fiz o mesmo para a esquerda e pronto: meu sprite da Torion estava lindo! A nave da abertura é o mesmo modelo renderizado, só que de frente! (risos)

E o que falar dos efeitos sonoros e música? A música, como podem notar pelos créditos, é de autoria de um sujeito chamado Wagner Carvalho. Ele era integrante de uma empresa nacional de desenvolvimento de jogos na época, a GreenLand Studios. No site deles, havia o portifólio com as músicas e eu tinha gostado de uma delas, casava com o tipo de jogo que eu queria fazer. Fiz contato com o Wagner, pedindo autorização para usá-la em Torion 2. Comentei que era para um projeto sem fins lucrativos, que seria divulgado em vários sites especializados. Acabei convencendo-o de que seria uma boa oportunidade de divulgação do trabalho dele que, então, permitiu a utilização da sua música.

Catei uns efeitos sonoros na rede, nem sabia a quem dar crédito. Até a música do boss de Streets of Rage usei ao chegar nos chefes de fase! (risos)

Com o passar do tempo o projeto foi ganhando forma, tornando-se bem interessante. Tinha o hábito de sempre atualizá-lo no site para que as pessoas pudessem acompanhar o andamento. Nisso, dois rapazes se ofereceram para contribuir. Acredito terem notado que o projeto era algo sério, que eu não estava para brincadeira. As aptidões deles casaram com minhas necessidades e eu os aceitei de bom grado. O Márcio Rogério fez uns sprites bem legais para o jogo. Sabe os chefes de fase? São dele. O Roberto Radke era bom em fazer músicas, então encomendei algumas composições. Aquela música executada ao passar de fase é dele. Muito obrigado rapazes!

Mas, a parte artística mais complexa do jogo foi, de longe, o mapa. Lembram que eu falei sobre tilling no post sobre Zanac, sobre o trabalhão que dá fazer aquilo? Pois bem, um grande companheiro de faculdade, Andrey Santana (não é o do Cosmic Effect) deu uma ajuda e tanto. No CDX, havia uma amostra de como fazer tilling, inclusive com um mapa pronto que exibia até mesmo parallax vertical. Tudo que precisava estava lá, naquele exemplo.

Então, Andrey pediu que eu lhe explicasse o funcionamento do editor de mapas, como isso funcionaria dentro do jogo e voilà: em poucas semanas ele produziu um mapa com cenário urbano que ficou de cair o queixo. Abusei: pedi para colocar um estádio no cenário, como aquele estádio de beisebol do Tokyo (Scramble Formation). Sempre babava com aquilo quando ia ao fliperama! Sabe o que ele fez? Pegou uma foto de satélite do Estádio Olímpico de Sydney e colocou no mapa (em tempos pré-Google Earth). Putz, esse cara é bom ou não é?

As armas… as armas!!!

Foi muito interessante programar essa parte. Quem já jogou Zanac percebeu que Torion 2 tem armas parecidas. Os tiros simples (até 3 no máximo) e as armas extras estão aqui! Isso foi descaradamente baseado em Zanac (risos)! Vou falar um pouco sobre elas:

– A arma do bumerangue. A mais chata do jogo e só a deixei ficar por não ter encontrado sprites melhores na Internet. Fiz a programação para que fosse e voltasse ao ponto inicial, dando até um efeito legal. Ficou parecido com Knightmare?

– As esferas que giram ao redor da nave. Era minha arma extra favorita em Zanac, não podia faltar em Torion 2. Fiz um upgrade baseado no que eu tinha visto em Super Aleste do SNES. Desta vez, as esferas giram em sentidos diferentes, em órbitas elípticas. Gostaram? Posteriormente, percebi que a arma era poderosa demais, tornando o jogo fácil. Então, implementei um sistema que descresce a força das esferas à medida em que ela colidia com os inimigos ou seus tiros. Percebem que elas vão clareando até desaparecer por completo? O nome deste efeito é alpha blending e o CDX já trazia de bandeja para nós.

– O laser. Foi o Andrey quem me cobrou esta. Todo jogo de nave precisa de uma arma laser destruidora. Por sorte, achei um sprite perfeito para os meus propósitos, foi só implementar.

– Os robôs que seguem a nave. Baseado numa arma que adorava no Super Aleste. Achava incrível a maneira como se movimentava, seguindo os passos da nave principal. Esta aqui foi a mais trabalhosa de implementar, mas a que trouxe mais satisfação pessoal quando pronta. Lembro que escrevi a lógica num pedaço de papel, depois de muito quebrar a cabeça. Mas, a lógica ficou tão boa que quando fui programar o que havia pensado, funcionou logo de primeira. Dei um pulo de alegria naquele instante, como se tivesse vencido um boss bem difícil!

A matemática está em toda parte.

Eu detestava matemática na escola. Pode parecer estranho para alguém que citou tudo isso sobre lógica, mas não suportava a disciplina. Inclui até uma recuperação no meu histórico escolar.

Quando comecei a programar Torion 2, percebi que não havia escolha, a matemática estava em todo lugar. Através da trigonometria, pude posicionar as esferas e fazê-las girar ao redor da nave. Calculando ângulos, fiz os tiros dos inimigos inteligentes. Eles sempre miram na nossa direção, não atiram de qualquer maneira.

Comecei até a gostar da “coisa” depois que vi uma utilidade prática. Ah, se a matemática fosse ensinada desta maneira nas escolas…

Colisões: o pesadelo!

Sabe quando a tela de um jogo torna-se cheia de inimigos e notamos um frame drop e vira aquela lerdeza? Não é o fato da tela estar cheia de sprites que torna o jogo mais lento, são os cálculos das colisões! O código testa o tempo inteiro se nossos tiros atingiram os inimigos, se os tiros inimigos nos atingiram, se as naves inimigas nos atingiram… imaginem que, se um jogo roda a 60 FPS, testamos 60 vezes em um segundo por todo tipo de colisão que possa ocorrer. O C++ faz isso mais rápido que as outras linguagens, por isso jogos feitos nessa linguagem costumam ter melhor desempenho. Games que rodam numa taxa de quadros estável normalmente tem um bom sistema de colisão.

Um dos motivos de um shoot’em up ser mais simples que um jogo de plataforma é o fato de não precisarmos testar as colisões com os cenários. Num plataforma isso é realizado o tempo inteiro, além das colisões com os inimigos. Isso não ocorre num shmup 2D.

Existem algumas técnicas de detecção de colisões. Em Torion 2, foram utilizadas dois tipos: colisão por sobreposição de retângulos e colisão pixel por pixel. Uma breve explicação:

– Sobreposição de retângulos. Um sprite é sempre retangular. Quando a figura é não-retangular, definimos uma cor no sprite como cor de transparência. Assim, quando o sprite é renderizado, aquela cor que definimos com cor de transparência não é exibida na tela. A detecção de colisão por sobreposição de retângulos testa apenas se 2 retângulos se sobrepuseram. É uma técnica pouco precisa, mas muito rápida.

– Pixel por pixel. É a técnica mais precisa, porém custosa em termos de processamento. Aqui, quando dois retângulos de sprites se sobrepõem, pegamos a área de interseção dos retângulos e testamos pixel por pixel se um determinado pixel é não transparente nos dois sprites em colisão. Complicado, não é? Mas é para isso que serve o engine: para nos livrar destas dores de cabeça!

Percebi que não dava para detectar todas as colisões do jogo usando pixel por pixel, isso tornaria Torion 2 lento. Na época, os PCs não eram tão potentes quanto os atuais, ainda tínhamos de espremer recursos. Optei em usar pixel por pixel apenas nas colisões em cima da minha nave, já que se eu usasse a sobreposição de retângulos, corria o risco de um tiro nem passar perto da nossa nave e nos matar. As colisões dos inimigos foram feitas com retângulos mesmo, pois se torna altamente aceitável para quem joga (risos).

Gameplay: a parte mais complexa!

Esta foi, disparadamente, a pior parte do projeto. Vocês não imaginam o trabalho que é fazer 30 segundos de jogo! Precisa realmente de gente especializada, não tinha mais dúvidas acerca disso.

Fazer um jogo que seja interessante, que não frustre o jogador, que o estimule pensar estratégias de combate; com a dificuldade progressiva… é uma arte. Percebi não ter o perfil para isso, pois a minha paciência é quase zero (risos).

Para que outra pessoa possa fazer o gameplay do jogo (tarefa que sobrou para o colega de faculdade Andrey), desenvolvi um layout para um arquivo em texto simples. O jogo estava pré-programado para ler esses TXTs. Bastava seguir o layout à rigor que o jogo se comportaria conforme desejado, dispensando recompilações. Então, foi só jogar a bomba nas mãos do Andrey (risos).

Lembro de um acontecimento engraçado. Ainda durante a implementação, pedi para uns amigos o testarem. Um colega de trabalho comentou ter um sobrinho vidrado em jogos. Ele, então, levou Torion 2 para o guri testar. No outro dia, trouxe o veredito do garoto: “o jogo é bom, tio, mas é fácil demais!”

Como assim “fácil demais”? Putz… podia começar meu dia sem essa, não é? Ferido no meu orgulho, disse para ele que iria dar um jeito nisso. Comecei a editar os TXTs, aumentando todos os valores, enchendo a tela de inimigos: queria ver aquele guri falar alguma coisa agora… Bom, só sei que o jogo ficou tão difícil que nem eu mesmo consigo terminar (risos)!

Conclusão: atingi meus objetivos?

Apesar de nunca ter terminado o jogo (só tem 2 fases), acho que fiquei satisfeito com o resultado. Torion 2 não ficou tão dinâmico quanto eu pretendia, o gameplay precisa de sérias melhorias, mas fiquei com a sensação de que poderia fazer qualquer jogo deste estilo, caso desejasse. A parte técnica está lá, bastava mais dedicação, experiência e as pessoas certas nos momentos certos do projeto.

Nunca mais vi os jogos 2D da mesma forma depois que participei deste projeto. A gente passa a ver as coisas com outros olhos, sabe?

E vocês? O que acharam de Torion 2?

Ah! E o resultado do concurso? Sei lá… o que eu queria, já havia conseguido!

[Nota do Cosmonal: Capturei o gameplay completo do Torion 2 para quem desejar vê-lo em ação (vídeo abaixo). Quem quiser, o jogo completo está disponível para download – link logo após o vídeo!]

Download Torion 2!
(Windows XP/7)

Basta descomprimir o arquivo baixado em qualquer pasta e executar “Torion2.exe”.
Iniciará automaticamente, em 640 x 480. Não há necessidade de nenhuma configuração.

* * *

Jamestown: Legend Of The Lost Colony (PC)

Amigos do Cosmic Effect: estamos iniciando uma série com posts sobre jogos independentes. Muitos de nós já sentiram que orçamentos milionários e cutscenes cinematográficas não são garantia de grandes momentos com o controle na mão.
Grandes idéias andavam escondidas nas mentes dos desenvolvedores independentes que, finalmente, ganharam o espaço que lhes é merecido através da Internet e redes privadas dos consoles modernos.
Nosso blog é 80% retrogaming e 20% next-gen, então… nada melhor do que batermos um bom papo sobre os ótimos títulos indie que adornam esta geração, não acham? :)
O artigo de estreia é do Heider Carlos, do 1/2 Orc e um apaixonado por jogos independentes. Ele nos contará sua experiência com o recém-lançado “Jamestown”.
Espero que gostem!

Por Heider Carlos

Jamestown é um shmup vertical steampunk indie. O jogo tem leves inspirações históricas: Jamestown foi a primeira colônia dos Estados Unidos, estabelecida em 1607. E termina por aí. Você joga com cowboys montados em espaçonaves, enfrentando uma aliança entre espanhóis e marcianos. Não tem como não amar isso :D O estilo é debochado como Metal Slug, embora as cut scenes tenham um visual de hqs dos anos 90. E ninguém é obrigado a ver nenhum segundo de história: se quiser é só pular direto pra ação, uma opção sempre bem-vinda.

Jogos também têm suas modas. E um estilo visual que voltou com tudo foi o pixel art. Se antes era questão de limitação técnica, hoje é estilo ver os pixels estourados, verdadeiros mosaicos de quadrados coloridos. É um efeito que, quando bem utilizado, fica muito belo. E em Jamestown o trabalho foi cuidadoso. Saber distinguir tiros do cenário é essencial em shmups e, mesmo com o enorme colorido das fases, é simples e instintivo saber o que está acontecendo. Assista um vídeo do jogo em movimento pra notar a harmonia com que ele foi feito. O design dos inimigos e cenários é bem feito, criativo e variado.

A música também é de altíssimo nível. Jamestown nada contra a maré e traz músicas mais eruditas, e não remix ou músicas eletrônicas genéricas. Cada fase tem músicas próprias. São temas bastante épicos, que caem como uma luva na jogabilidade. É uma pena que a trilha sonora não tenha sido liberada para download.

A última fase, em particular, é incrível. Com balas voando pra tudo quanto é lado, armadilhas espalhadas, blocos que se mexem pra abrir caminho pro jogador e um fundo sonoro épico – a imersão é incrível. É belo de se ver, e emocionante de jogar.

O jogador começa com 3 créditos e cada um dá direito a 3 vidas. Assim sendo, temos 9 vidas por fase. É possível acessar diretamente o estágio que desejar e, ao morrer, continuamos do mesmo lugar, invulnerável por um certo tempo. O jogo é desafiador, mas como não te obriga a voltar a cada erro, não frustra. E assim impera o sentimento “dessa vez vai” e “só mais uma tentativa” :D Quem deseja um desafio casca grossa pode liberar modos com menos vidas, onde é necessário transpor todas as fases em sequência. Boa sorte.

Outro fator que evita a dificuldade excessiva é o fato de não existir nada mais, além de dinheiro, para coletar durante as fases. Então, quando o jogador perde uma vida, as armas e poderes não são perdidos, como em Gradius e em boa parte dos shmups.

A campanha do Jamestown pode ser considerada curta. Jogando direto, é possível terminá-lo em menos de uma hora. Os menos habilidosos (eu incluso) devem levar mais tempo. Demorei aproximadamente 3 horas pra terminar, jogando desde o nível de dificuldade normal, e fazendo vários desafios no caminho. Se, por um lado a duração é pequena, por outro isso é uma benção – para quem não tem tanto tempo para investir e deseja curtir um título com ação ininterrupta.

Mesmo com a campanha não muito longa, há muito mais o que  fazer. Com o dinheiro coletado nas fases, é possível adquirir naves e bônus, além de liberar modos de jogo e desafios. Alguns são de arrepiar os cabelos.

O jogo foi desenvolvido para ter achievements, ou conquistas. Poucos gêneros combinam mais com achievements que os desafiadores shmups. Eles ficaram bem distribuídos: o jogador sempre está a poucos minutos de uma nova conquista, o que serve como motivação adicional para continuar.

Jamestown é um jogo excelente. E fica ainda melhor jogando com os amigos: suporta multiplayer local para até 4 pessoas, e dá pra jogar no teclado, mouse e controle usb. Cada segundo deste game empolga, uma experiência memorável. É um grande exemplo das vantagens dos jogos indies: despretensioso, extremamente divertido e o tipo de projeto que dificilmente veria a luz do dia se dependesse dos grandes estúdios.

* * *

Este é o primeiro artigo desta série. A partir do próximo post, os links
para todos os artigos da série até ali estarão disponíveis no final.

Déjà Vu

Por Euler Vicente

Jogando Killzone 2 do PS3, não pude deixar de me incomodar com os constantes loadings que esse jogo faz. E não me refiro à telas de loading de início de fase, com um CGI bonitinho para mascarar o carregamento: são loadings praticamente no meio da ação! Tomei alguns sustos pensando, inclusive, que o console poderia ter travado. Vem na minha memória o fantasma do YLOD em cada um dos congelamentos.

Porém, minha jogatina em KZ2 me fez lembrar do passado: da primeira vez que vi um jogo travando durante as fases para carregar.

Foi em 1988 ou 1989, quando morava em Itabuna (interior da Bahia). Estava numa festinha de aniversário de um amigo, quando ele me convidou para ver o MSX que o vizinho tinha. Lembro bem que o dono do computador em  questão morava no andar térreo e quando entrei no seu quarto, vi um Hotbit com um drive 5 e 1/4 (coisa de “barão” na época) rodando um jogo de nave que nunca tinha visto antes. O jogo era bonito mesmo! Tinha uma armas legais, mas não sabia qual era aquele título. Só depois que ele perdeu todas as vidas e o jogo foi para a tela de apresentação, descobri do que se tratava: era o lendário Nemesis.

Uau! Então esse era o tal do Nemesis! Puxa! Bom mesmo, hein? Mas, achei uma coisa muito estranha. Por que o jogo “travava” a todo momento?

Tempos depois fui equipando meu Expert: ganhei um drive 5 e 1/4, um cartucho MegaRAM e por fim a conversão para MSX 2.0. Obviamente, Nemesis logo foi adicionado à minha lista de games, mas sempre fiquei na dúvida do por quê dele ser o único jogo a ter uma versão para MegaRAM (que NÃO travava) e uma outra versão para o MSX normal (aquela do vizinho do meu amigo).  Afinal de contas, Nemesis era um jogo feito para MegaRAM ou não?

Somente anos depois, graças ao Google, obtive a resposta.

Nos anos 80, algumas empresas japonesas lançaram cartuchos de jogos com capacidade de expandir a memória RAM do MSX de forma a rodar jogos mais elaborados, que exigissem mais memória para rodar. Algo parecido com o que acontecia no SNES com o Super FX, só que os chips adicionais eram apenas memória extra. Esse cartuchos expandiam a capacidade da memória do MSX de 64kB para 128 e até mesmo 512kB. Foram surgindo vários títulos de qualidade inquestionavelmente superior, como o F1 Spirit, Maze of Gaulious e o próprio Nemesis.

Mas, a década de 80 foi a era da chamada “reserva de mercado” no Brasil. Para quem não sabe do que se trata, o governo brasileiro impôs uma série de normas com o intuito de proteger a incipiente indústria nacional de tecnologia da concorrência estrangeira. Ao invés do Estado incentivar a indústria a crescer e tornar-se competitiva, acompanhando o desenvolvimento tecnológico que acontecia nos países de “primeiro mundo”, o governo preferiu blindar a nossa indústria da concorrência externa para que não quebrasse. O efeito colateral:  vivíamos num país uma década atrasado.

Assim, a pirataria nos anos 80 não era apenas uma questão de economizar dinheiro comprando mais barato, era a única opção que existia.

O famoso jeitinho brasileiro resolveu o problema. Aproveitando-se do fato de o MSX ter sido concebido para ser um padrão de computadores que oferecia total compatibilidade entre os diferentes modelos, sabia-se que qualquer hardware/software comprado no exterior funcionaria aqui sem problemas. Então, as pessoas passaram a trazer de suas viagens ao exterior muitas novidades. E alguns cartuchos MegaRAM caíram nas mãos das pessoas certas, para nossa felicidade!

Tiveram a idéia de extrair o jogo do cartucho, alteraram o código do Nemesis original para que ele fosse lido a partir do disco. A “nova versão” de Nemesis copiava para a memória apenas o que estava sendo realmente utilizado no momento, ao invés de carregar tudo de uma só vez para a RAM, como era praxe nos jogos da época. Assim, um jogo que ocupasse 128kB de espaço em disco, poderia ser jogado num micro de 64kB!

Essa adaptação genuinamente brasileira nos permitiu experimentar jogos mais avançados do que seria possível com o hardware disponível por aqui, bastava ter de aceitar os “travamentos”.

Pouco depois, lançaram o cartucho de expansão MegaRAM no Brasil. Somente o cartucho com o chip que expandia a memória, sem a ROM com o game – algo como parecido com os cartuchos de memória extra que podem ser comprados para o SEGA Saturn. Dessa forma, bastava colocar o cartucho MegaRAM no slot frontal do Expert e mandar rodar os jogos adaptados direto do disco, como o nosso Nemesis. E o melhor é que já havia um bom acervo de jogos adaptados por aqui. Mas, isso é um outra estória…

Bom amigos, é isso. Quis compartilhar com vocês a sensação de déjà vu que senti jogando Killzone 2…  quando vi pela primeira vez o Nemesis travando para carregar no querido MSX…

* * *

Os Shoot’em Up Estão Acabando?

Por Euler Vicente

Outro dia conversando com o Eric sobre opções de compra na PSN, nos deparamos com uma realidade decepcionante: Onde estão os nossos amados Shoot’em Up?

Os “jogos de nave” ou simplesmente Shmups formam um subgênero dos shooters, onde naquele o jogador geralmente controla uma nave solitária que combate centenas de inimigos. Este gênero teve seu auge nos anos 80/90 com sucessos  memoráveis como: Space Invaders, Galaga (Fantastic! por aqui), Xevious (o nosso Columbia), Tokyo, Gradius, Zanac, R-Type e muitos outros.

Pessoalmente, é meu gênero favorito. Joguei muito Zanac no MSX. Quando ia ao fliperama, alternava entre Xevious ou Tokyo; cresci com eles e tenho acompanhado com tristeza o declínio do gênero. Talvez o último suspiro dos shmups nos consoles foi no Dreamcast. No PS2, alguns poucos bons jogos foram lançados como: Gradius V e R-Type Final, mas isso é muito pouco. Thunder Force VI não conta, de tão ruim que ficou.

O que teria provocado o declínio de um gênero que fazia tanto sucesso há alguns anos atrás? Pretendo levantar um debate sobre o assunto, pois creio que muitos de nós andam se perguntando sobre isso.

Vamos aos motivos que, primariamente, podem ter causado a queda do gênero nos dias atuais:

1 – Shmups não têm roteiro.

Sempre tentei imaginar um roteiro que se encaixasse num contexto de um típico Shoot’em Up. Uma nave sozinha lutando contra um milhão de inimigos? Isso não faz sentido algum, realmente. Alguns jogos  ainda tentavam colocar uma historinha antes do jogo começar, mas nunca vi uma que me convencesse. Como se fosse uma tentativa de dar uma maior qualidade à produção e tal, mas sinceramente isso não faz a menor diferença. Shump não é um gênero onde deve-se preocupar com o roteiro. O aspecto que devem observar é puramente o da jogabilidade. Para quê roteiro quando se tem o gameplay perfeito de um Ikaruga?

Atualmente,  games estão cada vez mais se aproximando do cinema. Roteiros cada vez mais complexos são criado para os jogos e a exigência nesse aspecto tem sido grande. Não bastam gráficos bem feitos e boa jogabilidade, a rapaziada de hoje em dia quer uma história convincente e, de preferência, bem complexa. Culpa do Mr. Kojima! Acostumou mal os gamers da nova geração e agora ninguém mais quer saber de jogo sem roteiro.

2 – Estagnaram tecnicamente.

Vi  um vídeo de um Shoot’em Up lançado recentemente para o PS3 na PSN: Soldner X-2: Final Prototype. Isso é para o todo-poderoso PlayStation 3 mesmo? Achei que tinha assistido uma sequência de PS2 ou Dreamcast por engano :-)

Parece-me que desde o surgimento dos primeiros Shmups 3D no PS1, muito pouca coisa mudou. Não vejo um salto gráfico nesses jogos que acompanhasse o gigantesco salto de hardware que os consoles deram. Esse jogo do PS3 que eu citei há pouco poderia ser feito tranqüilamente para um console da geração anterior.

Quando se está acostumado com God of War e Uncharted, os gráficos desses jogos chegam a doer nos olhos. É muito simples e naturalmente as pessoas foram perdendo o interesse. Porém, olhando pelo lado das desenvolvedoras, parece-me que esse gênero de jogo não dá muita margem para grandes inovações no aspecto gráfico. Será Gradius V o limite para um Shoot’em Up?

3 – Falta de investimento das desenvolvedoras

É uma conseqüência direta dos dois primeiros. Se não há gente interessada, não há o porquê de se investir, certo? Mas,  pergunto se aqui não cabe a teoria Tostines: vende mais porque é fresquinho ou é fresquinho porque vende mais? Ou no contexto desse post: vende pouco porque não tem qualidade ou não tem qualidade porque vende pouco? Sinceramente não sei responder :-) Minha insônia vai voltar com tudo agora que estou com essa dúvida na cabeça…

Será que se alguma desenvolvedora decidisse apostar suas fichas no reerguimento do gênero, investindo uma grana alta num projeto de grandes proporções, venderia tanto quanto Call of Duty? Acredito que ninguém ainda teve essa coragem, afinal de contas com dinheiro não se brinca, né? Com o pensamente capitalista que as grandes produtoras têm, só vamos ver Shmups de produtoras pequenas. Projetos típicos de PSN, Live e jogos free para PC.

Conclusão

Amantes dos shooters “de verdade”: nós viveremos de emuladores daqui em diante. Com investimentos cada vez maiores para se produzir um jogo, ninguém vai querer correr risco de lançar algo que possa não vender. E o que vende hoje é Halo e Metal Gear.

* * *