Anúncios

A história de um emulador

Não é todo dia que você esbarra em alguém que efetivamente programou um emulador de videogame. Todo retrogamer, colecionador e até aquele nostálgico ocasional que digitou “jogar atari online” no Google pra lembrar da cara de River Raid deve muito a estes verdadeiros herois da programação.
Amigos do Cosmic Effect, gostaria de apresentar o Alan Freitas, 32 anos, residente na capital federal deste país. E, falando em ser brasileiro, este cara não desistiu e… escreveu seu próprio emulador de Master System. Insisto para que acompanhem a história do emulador do Alan, que arregaçou as mangas e saiu da tela preta!
O artigo está genuinamente emocionante. Alan, seja bem-vindo!

Uma breve retrospectiva

Faço parte da geração nascida na década de 80, tendo acompanhado o universo dos jogos eletrônicos desde o estrondoso sucesso do Atari 2600. No início dos anos 90 eu já tinha o console há alguns bons anos.

Certo dia, um vizinho me chamou para ir até a sua casa onde vi algo impressionante: o jogo Choplifter rodando no seu Master System.

Aquilo que presenciava era, de fato, um salto qualitativo muito substancial em relação ao que já estava acostumado a ver no velho Atari. O jogo era muito dinâmico, tinha uma ação ininterrupta, seus gráficos eram espetaculares e a música, empolgante.

Lembro de ter jogado um pouco e o meu desempenho não foi dos melhores. Mas isso não importava, pois o meu objetivo estava claro: eu precisava ter um Master System.

O 8-bit da SEGA.

Chopper Command do Atari 2600.

Choplifter do Master System. A evolução era notável.

Algum tempo depois ganhei o console e, ao longo dos anos seguintes, tive muitos bons momentos com ele.

Minha rotina era semelhante a de muitos jogadores brasileiros: devido ao preço dos cartuchos e a uma certa disciplina parental, o esquema era alugar os jogos no sábado, jogá-los intensamente ao longo do fim de semana e devolvê-los na segunda-feira.

Pude apreciar boa parte do catálogo da plataforma, embora sempre restassem alguns títulos cujos gráficos se mostravam bastante atraentes nos encartes que acompanhavam o console, mas eram impossíveis de se encontrar nas locadores as quais tinha acesso.

Vem à memória o jogo Basketball Nightmare, com uma cena espetacular de um garoto fazendo uma cesta, em close.

Imagem chocante no encarte do Master System…

O ponto alto do Master System foi o jogo Phantasy Star, ao qual dediquei várias horas com amigos. Sei que é chover no molhado, mas a qualidade deste título, sobretudo se levarmos em conta quando e para qual plataforma foi produzido é algo que impressiona até hoje.

Pela primeira vez pude, em um jogo, acompanhar um enredo com um certo grau de desenvolvimento, em uma escala verdadeiramente épica (estamos falando de viagens espaciais entre três planetas), com vários mistérios a solucionar e, claro, gráficos e sons de altíssima qualidade.

Impossível não admirar a fluidez com que os extensos labirintos são percorridos, assim como a bela arte realizada principalmente nas cutscenes (outro aspecto inovador) e nos monstros.

Phantasy Star, um feito maiúsculo.

Como muitos de nós, guardo um certo arrependimento por ter vendido o console com a finalidade de seguir à próxima geração. Naturalmente, precisava do dinheiro para comprar o poderoso Mega Drive, que chegava proporcionando um outro avanço tecnológico espetacular.

O nascimento da idéia

Saltemos para o ano 2003. Após concluir a graduação em Computação, senti vontade de trabalhar em um projeto no qual pudesse exercitar alguns dos conhecimentos mais relevantes estudados na universidade.

Ambicionava explorar um pouco mais a parte de arquitetura de computadores e também computação multimídia, em um contexto de programação orientada a objetos.

Tive a idéia de criar, do zero, um emulador de Master System na linguagem C++. Parecia perfeito: os requisitos técnicos e a paixão pelo tema estavam lá, juntamente com um nível de desafio apreciável. O codinome também estava escolhido: Arisa.

Arisa. Ou Alis Landale.

Definindo o escopo

Certamente que não havia necessidade de, do ponto de vista prático, desenvolver um emulador de Master System. A plataforma já contava com vários emuladores muitíssimo competentes, cada qual com sua vocação: velocidade, acurácia, filtros, ferramentas de debug, etc.

Não se tratava, pois, desde o início, de uma iniciativa para trazer à cena mais um emulador disponível na Internet para download. Como já exposto, tratava-se de uma espécie de exercício particular.

FreezeSMS, Meka, Fusion e SMS Plus.

Conhecendo a arquitetura

Decisão tomada, era necessário entender como funcionava a máquina projetada pela SEGA. Para tal, comecei a buscar informações sobre a plataforma.

Nessa fase o site SMS Power se mostrou de grande valia, reunindo muita documentação com excelente nível de detalhes.

Placa de circuito do Master System. O chip central, no alto, é a CPU Z-80.
Foto: classiccomputer.de

Emulando o Z-80

De importância fundamental em qualquer computador, a CPU é candidata óbvia a ser emulada primeiro. Busquei livros e documentações online sobre o Z-80, o processador central do Master System.

Consideremos que o jogador apertou o botão de pulo no Sonic the Hedgehog. Muita coisa acontece:

  • Entrada: é feita a leitura do estado do botão, ou seja, apertado.
  • Lógica: é feita uma verificação se Sonic encontra-se sobre o solo ou uma plataforma, o que viabiliza o salto.
  • Aritmética: o movimento de salto é calculado, levando em consideração o estado presente do personagem (posição, velocidade, etc) e a simulação física concebida pelo programador (gravidade, inércia, etc).

Como compreender o coração do Master System?

Uma questão de interpretação

Uma técnica apropriada para a emulação de um processador como o Z-80 é a chamada interpretação.

Programar um interpretador basicamente consiste em criar, em uma determinada linguagem de programação, variáveis que guardem o estado de cada estrutura interna do processador, além de reproduzir o comportamento de cada instrução, à medida em que o programa é executado.

É, de fato, análogo ao trabalho de um intérprete: trata-se de um processo de tradução, em tempo real, de uma linguagem para outra.

As coisas não são tão simples…

Fazer uma descrição completa da arquitetura de uma CPU foge do escopo desse artigo, mas podemos dizer que o Z-80 é dotado de complexidade nada desprezível.

O processaodr da Zilog disponibiliza 252 diferentes instruções (opcodes, sendo mais exato) para o seu programador. 

Anúncio do competente Z-80 na revista Electronics em 1976.
(Imagem: domínio público)

Com isso, é evidente que a quantidade de código necessária para implementar o interpretador também é substancial.

Além de relativamente longo, o processo também trazia uma série de dúvidas: será que eu estava indo pelo caminho certo? Será que minha interpretação da documentação estava correta?

E se eu tivesse falhado em compreender algum conceito fundamental e todo aquele código sofresse de algum vício dificilmente sanável? 

Bem, não havia muitas opções a não ser estudar atentamente o material e codificar com cuidado.

Passei algumas semanas programando o interpretador. Implementei o que os programadores chamam de um “ambiente de debug”.

Amigos leitores, finalmente a palavra “jogo” aparece: com este ambiente pronto, eu podia acompanhar as alterações nos valores armazenados nas entranhas do Z-80 e da memória, durante a execução do Alex Kidd in Miracle World.

Apesar de não poder ter certeza, as coisas pareciam ir bem: eu conseguia ver que um jogo carregado parecia estar inicializando o processador e memória RAM emulados, num processo análogo ao de um PC ao ser ligado.

Também via o que parecia ser o carregamento de dados (gráficos, músicas?) na memória, entre outras coisas. 

Porém, era apenas uma visão “binária” naquele momento.

Não havia qualquer imagem do jogo rodando, como quando estamos, er… jogando.

Faltava outra peça-chave: o processador de vídeo (VDP).

Entrando no mundo dos pixels

Hoje temos nos PCs e consoles placas de vídeo com um poder computacional absurdo, que conseguem renderizar imagens com um grau de realismo realmente impressionante.

Na época dos 8-bit, os processadores de vídeo eram relativamente primitivos, e o limitado poder computacional das CPUs de então também deixava as coisas mais complicadas.

Como produzir gráficos atraentes e dinâmicos em uma velocidade aceitável? 

A resolução de 256 x 192 pixels do Master System pode parecer pífia para os padrões atuais, mas estamos falando de quase 50 mil pontos na tela. Era impossível manipular cada um deles de forma individual em tempo real. A solução clássica, simples e genial: Tiles.

Asterix, com os tiles ressaltados…

Como vocês estão carecas de saber, qualquer jogo da época, por mais complexos ou sofisticados que sejam os seus gráficos, é uma espécie de mosaico.

Os artistas desenhavam todos tiles de tal maneira que, arranjados corretamente, eles se integrassem de forma harmoniosa na tela.

…aqui, o conjunto de tiles usado na cena anterior…

Os tiles são formados a partir uma paleta de 16 cores para os sprites e mais 16 cores para o cenário.

Essas cores podem ser escolhidas dentro de um universo de 64 possíveis.

Paleta

…e, por fim, a paleta de cores da mesma cena.


Como estamos lidando com um hardware que possui muito pouca memória, se for possível reutilizar um mesmo tile fazendo seu espelhamento isso pode economizar bytes preciosos.

Assim, tínhamos belos gráficos em tela cheia.

Alguns efeitos colaterais curiosos apareceram. Inconsistência do ponto de vista físico era um dos campeões e hoje pode ser considerado um charme peculiar ao visual dos jogos eletrônicos.

Note a iluminação na cena abaixo.

Espelhamento de tiles em Phantasy Star.
Repare que a cena é perfeitamente simétrica, até nas sombras…

Tamanho não é documento

Após sentir-me seguro com a emulação do Z-80, o processador de vídeo era o próximo desafio. Menos código que o da CPU, porém com muitas particularidades e uma boa dose de complexidade.

É uma forma de conceber a montagem e exibição de imagens bem peculiar; muito diferente do que se faz na computação hoje em dia.

Aqui as inseguranças se intensificaram. No Z-80, eu inspecionava seu estado ao longo da execução. Dava pra ter uma impressão do funcionamento.

No caso do VDP… eu trabalhava às cegas, sem ter por muito tempo uma interpretação da representação binária em debug que me auxiliasse.

Fui em frente, esperando que meu entendimento dos documentos estivesse correto…

Uma grande emoção

Após algumas semanas, terminei a codificação da emulação do VDP. Junto com a emulação do Z-80 e das memórias RAM e ROM, também concluídas, isso deveria ser suficiente para executar um jogo comercial.

Claro que certamente existiam bugs no meu código; Mas, com sorte, talvez um jogo rodasse, ainda que de forma defeituosa.

A hora havia chegado: carreguei a ROM de Alex Kidd in Miracle World e após breves instantes de tensão…

 Nada além de uma tela preta.

Animador…

De certa forma, era esperado. Muito código e, pela própria natureza do problema que ele se propunha a resolver, um pequeno bug em qualquer trecho poderia causar uma falha em exibir qualquer coisa que lembrasse o jogo original.

Tentei outros jogos, com esperança de que algum funcionasse. Nada feito.

Um aspecto cruel de um emulador é que, diferentemente da maioria dos softwares, você muitas vezes não tem idéia de onde pode estar o problema do seu código. Isso porque o programa se comporta como a máquina na qual o jogo executa, mas o desenvolvedor do emulador pouco ou nada sabe sobre o código do jogo em si!

Paradoxalmente, é aí que reside a beleza pouco convencional do conceito da emulação: o jogo executando nada “sabe” sobre estar executando em um emulador, e não na máquina real.

A beleza de dar vida a um cartucho de Master System sem consumir espaço físico…

Por outro lado, o programador do emulador nada sabe sobre o código do jogo em si. Ele “apenas” implementa um software que se comporta como um hardware.

Não é necessário saber programar um jogo para aquela máquina. À medida que eu me embrenhava nas entranhas daquilo tudo, observando internamente a execução dos jogos… foi possível perceber a qualidade excepcional daqueles programadores.

Pude ver, desta vez com olhos de programador, quão impressionante eram seus resultados em plataformas tão limitadas.

Voltando aos bugs do nosso emulador. Foi um processo longo e tedioso. Todo programador sabe que criar código é bacana. Corrigi-lo, quase nunca. 

Após finalizar essa primeira revisão geral (dias depois), carreguei Alex Kidd in Miracle World novamente e… 

Escutou a musiquinha daí?

Funcionou! A tela de apresentação apareceu, mostrando várias cenas do jogo. Logo em seguida começou a demonstração: Alex Kidd percorria a fase em alta velocidade com a sua motocicleta!

Um momento de grande emoção, pois era o resultado de um longo trabalho sem resultados intermediários. Julguei, algumas vezes, que poderia ser, no fim, algo infrutífero de minha parte.

Mas não foi!

Alex Kidd: um cara maneiro.

Inevitável também o sentimento de nostalgia dos tempos da jogatina no Master System real. De alguma forma eu me aproximava um pouco mais daqueles admiráveis engenheiros, programadores, artistas gráficos, músicos, entre outros, que deixaram, com sua inteligência e criatividade, um legado tecnológico e cultural bastante relevante.

Uma mancada

Ao ver o game executando com aparente perfeição, o instinto falou mais alto: meus dedos deslizaram para o teclado, visando efetivamente jogar o jogo.

A demonstração seguiu, inabalada.

Claro: eu não havia implementado o input do joystick!

Ávido por jogar Alex Kidd sendo “empurrado” por Arisa, consultei correndo a documentação sobre o console, para aprender sobre o joystick do Master.

Até que foi rápido — bonus stage? — e pude, então, jogar Alex Kidd in Miracle World.

Mais algumas correções, rumo a uma conclusão 

Depois dessa primeira partida, rapidamente testei outros jogos. A maioria executou sem problemas, mas alguns apresentaram inconsistências, como comportamentos bizarros nas colisões ou nas cores. 

Corrigi mais alguns bugs, o que fez com que mais jogos executassem perfeitamente. Ainda restavam alguns detalhes que poderiam ser melhorados. Nesse período eu também comecei a programar a emulação do som. 

Havia, entretanto, uma nítida queda na motivação. Sentia que o desafio particular que havia proposto a mim mesmo tinha sido superado. Como nunca pensei em disponibilizar Arisa para terceiros, acabei abandonando o projeto aos poucos. 

Hoje não julgo provável retomar o desenvolvimento, mas foi algo no qual gostei muito de trabalhar. Sem dúvida foi um dos softwares mais legais que programei.

Valeu a pena.

“Linguagem de comunicação

Confesso que tive dúvidas sobre a redação desse texto no que diz respeito ao escopo.

Ao mesmo tempo que emuladores têm importância central no universo retrogamer, é muito fácil se aprofundar em questões excessivamente técnicas que podem alienar um leitor que, embora interessado no assunto, não esteja familiarizado com arquitetura de computadores ou programação. Dessa forma, tentei mesclar a tecnologia com os aspectos mais humanos e históricos.

Não sei se fui bem-sucedido, mas estou à disposição para tentar dirimir dúvidas, fornecer algum aprofundamento ou ainda esclarecer algum ponto que não foi devidamente explanado.

Muito obrigado aos leitores do Cosmic Effect!

* * *

Anúncios

Minecraft, O Software

por Danilo Viana

Minecraft é um sucesso completo no reino Indie e um fenômeno de vendas. O jogo criado por Markus Persson hoje é sinônimo de sandbox e prova que uma boa idéia — mesmo uma não original — quando bem implementada pode render não dois, mas centenas de milhares de minutos de fama.

Para os dois de vocês que sequer ouviram falar do jogo, Minecraft é um jogo tipo sandbox onde, utilizando cubos, é possível moldar completamente um mundo infinito, totalmente seu. É dado ao jogador total liberdade para destruir, recriar e reposicionar tais blocos criando praticamente qualquer coisa. Além disso, é possível criar centenas de itens — picaretas, espadas, cercas, portas — tudo a partir de materiais minerados no ambiente do próprio jogo e um curioso sistema de construção (chamado de Crafting) que é fácil de entender e divertidíssimo de experimentar.

O jogo começou a ser desenvolvido em 2009, tendo sua primeira versão “final” em 18 de novembro de 2011. Escrevo “final” entre aspas porque Minecraft é jogado por milhões de pessoas desde sua primeira versão preliminar, tendo faturado milhões antes mesmo de ser oficialmente lançado.

Para entender melhor do que se trata, vale uma espiada no vídeo que apresenta o trailer oficial. Tem apenas um minutinho e é bem bonito.

Verdade seja dita: existem milhões de sites e blogs que escrevem sobre Minecraft, apresentando reviews, dicas, guias, mods e pacotes de texturas. Com o objetivo de agregar algo novo para o leitor do Cosmic Effect, gostaria de trazer a ótica de um desenvolvedor de sistemas nesta abordagem. Se você não tem o mínimo interesse em programação e nenhuma curiosidade para saber como jogos funcionam, talvez essa leitura não seja para você — mesmo assim convido todos a me acompanharem nesta análise um pouquinho mais técnica, pois tenho certeza que encontrarão algo interessante para refletirmos juntos.

Um verdadeiro Sandbox

Esqueça GTA, Assassin’s Creed ou qualquer outro “sandbox” por aí. Em Minecraft você pode REALMENTE fazer o que quiser. A premissa do jogo chega a ser ridícula quando você diz em voz alta: um jogo sem objetivos, sem missões e sem NPCs (eles até existem, mas são meramente decorativos). Os inimigos estão lá apenas para criar um desafio, você não precisa enfrentá-los e se nem quiser vê-los existe um “modo criativo”, sem a presença de oponentes. O único objetivo fixo do é minerar e construir o que você deseja, tudo isso no tal mundo infinito — não é “virtualmente” infinito, como em “é tão grande que poucos acham o final” — é realmente infinito pois se você tomar uma direção e sair andando o jogo vai criando mais terreno eternamente, até literalmente o espaço em seu disco rígido acabar.

Ao refletir um pouco mais profundamente esta premissa, pode-se concluir que Minecraft tem um paralelo no mundo real: Lego. Não estou falando dos Legos atuais, temáticos e praticamente sem necessidade de montar nada; lembre-se do Lego tradicional, um balde de peças encaixáveis onde você constrói o que quiser e tiver tempo (e peças) para fazer. A diferença é que neste jogo virtual as peças são infinitas; você só precisa de tempo.

Como isto é possível? Jogos como Battlefield 3 e Skyrim criaram mundos gigantes, mas eles esbarram na barreira do espaço de armazenamento, memória; como um “joguinho” com download de 200 KB e que depois de instalado ocupa “só” 100MB consegue ter um mundo infinito? A resposta é simples: use blocos.

A primeira vez que vi Minecraft os gráficos chamaram a atenção: exatamente o que imaginava se de uma versão FPS de Final Fantasy (o primeirão, de NES), com seu cenário quadrado e construções apenas com ângulos de 90 graus. Bacana o estilo, como um tapa na cara de todos os fanáticos por gráficos, mostrando mais uma vez que eles não são tudo.

Ao jogá-lo mais um pouco, percebi que não se tratava apenas do estilo gráfico. Claro, cada textura tem apenas 16 pixels de altura e o programador poderia ter feito melhor se assim desejasse — de fato existem mods que permitem trocar as texturas por versões de 32, 64 e até 128 pixels — mas a ideia aqui não era apenas seguir um estilo gráfico. Era o nascimento da receita para mundos infinitos.

Cada vez que se inicia um novo mundo em Minecraft, um algoritmo estabelece um mundo aleatório, mas relativamente coeso. Existem zonas com florestas, outras com lagoas e após uma certa profundidade são encontradas cavernas e até algumas vilas de NPCs. Claro, o algoritmo comete alguns erros: vilas com casas cujas portas dão para a parede, mas como você pode mudar tudo, não é nada que um pouco de boa vontade e trabalho não conserte rapidamente.

Para que esse algoritmo funcione, os blocos são fundamentais. Já que o mundo é apenas um bando de cubos reunidos, tudo que se precisa é de um conhecimento prévio acerca das regras de cada bloco — blocos de grama e areia vão na superfície, blocos de água preenchem buracos nos de grama, blocos de pedra e minério vão no subsolo — e o mundo infinito está pronto para ser criado.

É uma ideia simples que define todo o estilo de Minecraft — aqui não existem fases ou mapas que necessitem de um level designer, tampouco houve necessidade de visitar locais icônicos para capturar texturas realistas. Ao tornar o mundo um conjunto de blocos com uma função simples, todo o trabalho de moldá-lo foi entregue ao jogador e chamado de gameplay. E ele agradece por isso.

Minecraft, o software de computador

Algo que, particularmente havia me surpreendido em Minecraft é o fato de ter sido desenvolvido na linguagem de programação Java. Para os não iniciados, a curiosidade está no fato de que Java nunca realmente emplacou como linguagem de programação para jogos eletrônicos. Os fantásticos títulos para consoles e PCs em sua gigantesca maioria são criados na linguagem C++ e , mais recentemente, a Microsoft conseguiu emplacar o C# (pronuncia-se Cê Sharp) através de seu framework XNA e o Xbox 360.

Java sempre foi uma daquelas linguagens que alguns tentavam provar que servia para jogos, mas ninguém dava a mínima — quando algo um pouco mais audacioso era criado, o programador gritava aos quatro ventos que usou Java e isso acabava servindo mais para desmotivar do que para promover. (Nota para os amigos da área: estou ignorando que os jogos para Android são em Java; para todos os efeitos, refiro-me ao Java que rodam nos computadores pessoais).

Eis que Minecraft surge e ninguém faz alarde algum acerca de como ele foi criado. Você faz o download, executa-o como faria com qualquer outro programa e, na remota possibilidade de você não ter o Java instalado, ele reclama e te direciona à instalação. Até esta reclamação é discreta, como se esse tal de Java fosse uma coisa que você deveria ter, como o DirectX que é embutido no Windows. Em momento algum o jogo informa que é um aplicativo em Java, você nem lembrará disso depois.

Esta sutil postura da rotina de instalação despertou meu interesse de imediato. Sabe quando você oferece uma lanche a amigo e somente depois comenta que é feito de repolho, a coisa que ele mais odeia no mundo? Mesma coisa.

E o que fica diferente por Minecraft ser feito em Java? Fora o fato que ele roda em qualquer plataforma que tenha a máquina virtual Java, absolutamente nada. Trata-se de um jogo muito bem construído e de ótima performance, inclusive com muitos mods que melhoram gráficos, adicionam recursos e até novos inimigos. Pois bem: para todos aqueles que defendiam a inabilidade da linguagem em alcançar o desempenho de jogos desenvolvidos em outras linguagens, Minecraft é um verdadeiro tapa com luva de pelica.

O ciclo de desenvolvimento também é bastante interessante. Nas palavras do próprio autor:

(…) my only true design decision is to keep it fun and accessible. There’s no design document, but there are two lists; one for bugs, and one for features I want to add but think I might forget.”

Em uma tradução livre, significa que ao invés de vastos documentos e incontáveis artes conceituais, o autor dá um passo de cada vez e adiciona apenas aquilo que acha interessante e divertido, ou que conserta eventuais bugs. Se após implementar algo, ele (ou os jogadores nos fóruns) achar algo sem graça, simplesmente vai lá e remove. Esta decisão significa que a equipe de desenvolvimento não tem medo de tentar um novo recurso que possa parecer interessante. Eles tentam; e removem em seguida caso não funcione bem. Não , você não precisa comprar DLC nem pagar assinatura; se você tiver comprado o jogo uma vez, terá eternamente a versão mais nova.

Jogo de criança… NOT

Minecraft é um jogo sobre coleta de recursos e construção utilizando estes recursos. À primeira vista, parece que a “construção” é meramente o reposicionamento dos blocos em uma forma diferente — como seria com Lego — mas o jogo conta com um recurso mais poderoso: a obtenção de novos itens combinando matérias primas.

Quer uma espada? Combine duas barras de ferro com uma vara de madeira; um machado ou uma picareta? Use três barras de ferro, ao invés de duas.

Como faço para diferenciar um machado de uma picareta, dois itens que usam os mesmos materiais e na mesma quantidade? Mantendo a filosofia da construção por blocos, Minecraft conta com um sistema de construção onde você “desenha” o item que quer; para obter uma espada, não basta fornecer duas unidades de ferro e uma de madeira: é preciso posicioná-los na tela de construção, na posição correta para formar uma espada. Imagine comigo: duas barras de ferro, uma abaixo da outra na vertical; logo abaixo, a peça de madeira.

A construção do mundo, a criação de itens montando a matéria prima… tudo isso torna Minecraft uma experiência recomendadíssima para crianças. Nada de violência e o aspecto de construção estimula muito a imaginação, não precisa nem dizer. Mesmo assim, é incrível o número de adolescentes e adultos jogando. Incontáveis vídeos, fóruns, páginas de wiki e blogs — todos com pessoas crescidas mostrando suas criações.

E como elas são fantásticas. Desde casas simples mas bem decoradas até reproduções fiéis de monumentos mundiais, como o Coliseu e a Estátua da Liberdade.

Além disso, o jogo conta com um interessante material chamado Redstone. Ele serve de fonte de energia elétrica no mundo do jogo. Esta fonte de energia pode ser combinada com pisos móveis, alavancas, portas lógicas, trilhos de trem e outros materiais, tornando possível a construção de verdadeiras masmorras, com direito a armadilhas, sistemas de defesas e até golens ativados apenas quando inimigos entram no recinto.

Jogadores criativos utilizam estes recursos para criar sistemas totalmente auto-suficientes, com carros de mineração que levam recursos minerados para casa do jogador e voltam com ferramentas novas (as ferramentas em Minecraft têm duração limitada), otimizando ao máximo a coleta de matéria prima.

Com todos estes elementos, Minecraft tem se tornado o símbolo do jogo para todas as idades. Qualquer um vai encontrar algo que gosta, seja a criança que quer apenas brincar com a montagem de blocos, passando pelo jogador casual que quer investir em seu pequeno “mundo tamagochi” um pouco a cada dia até os hardcores que implementam sistemas autômatos e mundos coesos dignos de MMORPGs.

Com isso, voltamos ao princípio básico de desenvolvimento de Minecraft — sem documentos, apenas desenvolvendo algo em cima da premissa “se for divertido”. É incrível ver como um método simples e até “desorganizado” como este gerou um jogo muito mais completo que produções multi-milionárias como Skyrim, World of Warcraft ou Call of Duty: jogos que seguiram modelos mais tradicionais de desenvolvimentos e que gastaram pelo menos metade de seu ciclo sem digitar uma única linha de código, apenas criando documentos para determinar ainda seria criado.

E finalmente concluímos

Minecraft não é para todos — o jogador que gosta de ser guiado e sente-se perdido na ausência de objetivos claros, provavelmente não vai gostar do título. Viciados em gráficos podem também achá-lo difícil de digerir, já será necessária  uma dose de imaginação talvez rivalizada apenas por jogos da era Atari. Mesmo assim, Minecraft é um dos jogos atuais que melhor representa o ato de jogar videogame. Desprender-se da realidade e interagir com um mundo fictício, tudo em nome da diversão.

Uma idéia como esta, alguns anos atrás, poderia causar risos na sala de reunião ou até a demissão de alguém. Um cético diria que não temos poder computacional suficiente para representar um mundo tão rico e dinâmico. Tudo que bastou foi um programador solitário e criativo se perguntar “e se os gráficos não precisarem ser bons? E se o jogador aceita-los até mesmo… terríveis?”. O que o levou à ideia básica: “e se usarmos blocos? Lego fez isso por anos, por que em um computador não daria certo?”

O sucesso de Minecraft é prova suficiente que, pensar fora da caixa, pode trazer excelentes resultados… 

* * *