Programar sistemas (as assim
chamadas “engines”) para dar suporte a jogos é uma
tarefa ingrata. A maior parte do tempo lidamos com decisões sobre
funcionalidades. É importante que elas sejam genéricas
e que possam responder a inúmeras situações, em
detrimento de uma programação mais específica,
que pode resultar em um processamento mais eficiente.
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 evoluirem 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 do jogo das formas 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.