Junte-se a isso a inadequação de determinadas linguagens à programação dinâmica dos jogos, onde os elementos que mais importam dizem respeito à parte gráfica, movimentos e toda sorte de malabarismos computacionais. Mas, como dizem, alguém tem que fazer o trabalho sujo, então, mãos à obra.

Por volta de 1996 deixei de lado anos de assembler (Z80, 8088, 80386, etc) por conta do predomínio do Windows no uso pessoal dos computadores. Fui dos procedimentos de programação mais básicos à programação orientada a objetos, usando como instrumento nessa jornada o Delphi. Foram anos de resultados importantes e principalmente de uma programação que por si só já era deliciosa.

Mas o mundo estava mudando e com ele a dinâmica do uso de equipamentos. O computador em si mesmo, quer seja no formato desktop, notebook ou netbook, estava perdendo terreno para devices mais simples de operar, os chamados “dispositivos móveis” (tablets, ipads, ipods, etc). E com essa mudança, o predomínio do Windows foi escorrendo pelo ralo. Vieram Ios e Android (só para ficar nos dois mais vistosos).

Com eles veio também o processamento à distância, que ganhou um apelido bem inusitado: “nuvem”. Já era hora portanto de migrar o trabalho para algo mais maleável que um executável que roda localmente, sob Windows. A resposta veio na forma de uma combinação nem tão estranha assim: html para a interface com o usuário, php para a programação e mysql para os dados dos jogos.

Nesta altura do campeonato (e isso aconteceu no final de 2011, início de 2012) as promessas acerca de um browser poderoso, especialmente feito para jogos, já estava ganhando corações e mentes. O tal do html5 já começava a ter adeptos, mas (e sempre tem um mas) ainda era cedo para apostar as fichas nele.

Outro ponto importante: os dispositivos móveis vão desde um tablet poderoso, que roda aplicações tão facilmente quanto um notebook, até um celular com tela minúscula e processamento capenga. Definir parâmetros e diretrizes num ambiente desses é complicado e se for para aceitar restrições, por que mudar de plataforma?

Some-se a isso o fato de os adventures migraram em duas direções distintas: uma foi parar nos modelos 3D FPS de altíssimo desempenho e exigências estonteantes em termos de recursos de hardware e outro foi para o lado da ficção interativa, onde as questões de recursos técnicos são de menor importância, valendo mais a elaboração de enredos, narrativas, etc.

Evidentemente que todo meu interesse estava nessa segunda vertente e a trinca html/php/mysql, juntando com o processamento remoto e mais a simplicidade na elaboração da solução, apontou de cara para um sistema “rodável” em qualquer coisa. De computadores a chuveiros elétricos; de tablets a geladeiras. O único requisito exigível portanto seria uma conexão à internet e um navegador qualquer. Do mais básico ao mais sofisticado, qualquer um daria (ou deveria dar) conta do recado.

E para não dizer que não ficaria “modernoso”, o desafio era adaptar a mecânica dos adventures tradicionais (comandos digitados) ao modelo fácil de usar, via dedos: touchscreen. Claro, todo dispositivo tem, de uma forma ou de outro, um teclado (ainda que virtual) mas a ideia em torno dessa nova direção contemplava também a eliminação desse mecanismo, ou seja, transformar uma narrativa e mecânica própria para comandos digitados em um modelo point & click simplificado.

O point & click, no caso dos adventures, surgiu ainda nos anos 80, quando os micros pessoais começaram a ganhar resolução, cores e mais adiante o mouse, como uma espécie de “evolução” ao modelo tradicional de comando digitado. Na verdade o point & click tentava facilitar a vida do jogador “mastigando” as soluções para os jogos. Não que isso fosse ruim, muito pelo contrário. Era uma nova forma de abordagem e que deu frutos por muitos anos.

Com a volta, ou melhor, com a popularização da tela de toque (touchscreen) a coisa toda do point & click ganhou ares de modernidade. E foi nesse embalo que, nos primeiros meses de 2012 comecei a portar o Amazônia para um sistema html/php/mysql.

Os primeiros resultados mostraram uma dura realidade: cada navegador “entende” o mundo de uma forma única e pessoal e isso praticamente inviabiliza o html puro. As soluções começam a ser apontadas: scripts, flash, html5, etc. Mas aqui o problema é recorrente: quanto mais sofisticada for a ferramenta utilizada, mais você corre o perigo de ir eliminando os devices que não obedecem rigorosamente aos requisitos da ferramenta, ou seja, a gente acaba voltando para o ponto de partida: se é para ser específico em relação a um equipamento, então porque não ir direto a ele?

De certa forma isso mata na raiz toda a mobilidade que o mundo moderno exige dos aplicativos. Perguntas do tipo “tem para android?”, “tem para Ios?”, “tem para PC?”, começam a se tornar frequentes e a exigência por portabilidade se torna cada vez mais crucial.

Aqui é preciso fazer uma observação: compilar um programa para cada sistema operacional disponível é uma coisa; fazer um jogo que roda em qualquer sistema, mesmo aquele que ainda não foi inventado, é outra coisa completamente diferente.

Com base nessas premissas, a solução foi simplificar todo o jogo a uma imagem apenas. A imagem usada para ilustrar a posição e “áreas clicáveis” nela. Pronto, o sistema inicial, que rodaria em qualquer dispositivo mostrou-se operacional. A primeira versão do Amazônia nesse modelo saiu inclusive dentro do facebook, como prova de que nenhuma linha a mais de programação ou adaptação seria necessária para ter o jogo em qualquer lugar.

A resposta, por parte do jogadores, a essa solução foi tão boa que foi difícil não pensar em ampliá-la para um sistema genérico de criação de aventuras interativas clicáveis. A base de tudo estava lá, funcionando de forma simples, direta e sem maiores problemas.

Foi então que, bem no início de 2013 surgiram as primeiras especificações do Micro Aventuras: tela de 720x480, três ícones de controle no canto superior esquerdo e uma linha de mensagens no rodapé dessa área.

Evidentemente que não se limita uma ferramenta a um único formato visual e a primeira evolução do MA, já na metade de 2013, foi introduzir uma proto linguagem de programação (chamando suas seções de “scripts”). Com isso o sistema ganhou poder de fogo para literalmente modelar a estrutura o jogo de formas as mais variadas possíveis, cujo limite seria a imaginação dos autores e criadores.

O Micro Aventuras portando está em processo de crescimento. Ainda não foi explorado em toda a sua potencialidade e daqui para frente é bem possível que possamos jogar aventuras cada vez mais sofisticadas nele. Isso sem contar que, a qualquer momento, a gente possa criar mecanismos de monetização das aventuras, promovendo assim uma estrutura que venha a ser comercializável, para as aventuras criadas nele.