Category Archives: Javascript

Exprimentando Vue.js – aplicando no /dev/All

Recentemente comecei a buscar frameworks JavaScript para serem aplicados em nossos projetos na itexto. Publiquei algum tempo atrás minha experiência de aprendizado envolvendo o Angular.js: chegou a hora de falar sobre o Vue.js.

Como fui parar no Angular.js

 

angular-js_600x400

Aprender Angular foi uma experiência muito enriquecedora para mim pois me pos em contato mais profundo com diversas ferramentas usadas no ambiente JavaScript, tais como o Gulp e o NPM.

O que mais gosto no Angular é a ideia de templates renderizados do lado cliente. Apesar de na esmagadora maioria dos nossos projetos boa parte da renderização ser realizada do lado servidor (diversas razões para isto, o que, por si só, já daria um post), em alguns casos a renderização do lado cliente nos parece a solução ideal.

Um dos nossos projetos em que os templates do Angular cairam como uma luva foi o /dev/All que, até a versão 1.8 usava este framework do lado cliente.  Não conhece o site? Abaixo você pode ver um print do mesmo:

devall_vue

Com o passar do tempo a arquitetura do /dev/All foi sofrendo algumas modificações, dentre elas a criação de uma API na qual estamos trabalhando aos poucos. Entre as chamadas desta API está a nossa busca, que é usada atualmente na interface do site com o usuário final.

A primeira versão do /dev/All era 100% renderizada do lado servidor. Com isto, sempre que o usuário paginava os posts ou realizava uma busca, todo o conteúdo da página era carregado novamente (ignorando os cacheamentos de JavaScript e CSS).

Este problema foi a razão pela qual na versão 1.8 do /dev/All passamos a usar o Angular na confecção da nossa interface gráfica. O resultado foi muito bom: os usuários agora baixavam uma única vez o código da página e em todas as chamadas subsequentes o Angular fazia o trabalho de atualização da interface.

Como encontrei o Vue.js

vuejs

Tivemos esta experiência bem sucedida com o Angular mas fiquei com a impressão de que ele era uma solução muito complicada para as nossas necessidades. A curva de aprendizado do Angular é muito íngreme: são muitos conceitos para que você comece a se tornar produtivo: controladores, módulos, injeção de dependências, inversão de controle, diretrizes. Minha única preocupação era a view: eu só queria um template que fosse renderizado do lado cliente e que tirasse proveito da nossa API.

Eu também queria algo com o qual pudesse reaproveitar conhecimentos que já dominava, como o jQuery: misturar Angular e jQuery é complicado para dizer o mínimo (sei que é possível, mas mesmo assim é mais complexo que o necessário).

Nisto passei por algumas soluções interessantes: Mustache, Rivets, Tangular (apenas 2Kb!) e mais algumas alternativas, dentre as quais estava o Vue.js, cujo primeiro contato foi feito totalmente por acaso através de um vídeo do Vedovelli.

Resolvi experimentar o Vue.js: o primeiro passo foi ler o seu guia para desenvolvedoresA leitura do guia me fez esquecer o Angular. Achei a documentação do Vue.js uma das melhores que já li: rápida, direta e curta. Terminada sua leitura você já consegue criar coisas interessantes com o framework.

(o guia do Vue.js devia ser usado como exemplo de documentação bem feita: virei fã)

A impressão que tive do Vue.js foi a de se tratar de um “Angular” fácil de aprender. Em aproximadamente três horas de estudo você já consegue criar aplicações com o Vue.js: no caso do Angular levou pelo menos uma semana para começar.  Vi esta experiência de aprendizado se repetir com Lucas, nosso estagiário na itexto.

A versão 1.9 do /dev/All, publicada no dia 19/6/2016 substituiu o Angular pelo Vue.js (usamos a versão 1.0). Quantas linhas de código JavaScript precisamos escrever para criar toda a interface do site? 30 (!), incluindo o boiler plate padrão do jQuery ($(document).ready).

O jQuery faz as chamadas ao servidor e o Vue.js renderiza o resultado para nós. É simples assim. :)

Outras coisas que gostei no Vue.js

Além da excelente documentação e facilidade de ser usado com outras bibliotecas (jQuery), houve outras razões pelas quais este framework me ganhou.

API fácil

A API do Vue.js é muito simples: essencialmente você só precisa conhecer o construtor Vue. E não só o guia é fácil de ler: a documentação da API também é excelente!

Levou um tempo até que eu me habituasse com o modo como a injeção de dependências é realizada no Angular (especialmente os problemas que podem surgir durante a minificação e “uglyficação” do código). No caso do Vue, como é focado apenas na view e não há controladores, tudo fica muito mais fácil.

Tem o que gostei no Angular

A sintaxe dos templates do Vue é muito parecida com a do Angular. Tanto é que não precisei reescrevê-los ao migrar para o Vue.js: a grosso modo bastou trocar as diretrizes “ng-*” por “v-*”.  A mesma sintaxe “mustache” se mantém.

Também há diretrizes, como o Angular, assim como filtros. A diferença está na facilidade de aprendizado.

Outra similaridade importante: também implementa o data binding bidirecional. Este recurso é muito interessante, especialmente quando se quer construir interfaces de cadastro mais complexas como, por exemplo, formulários do tipo mestre-detalhe ou mesmo simulação de planilhas (para estes dois casos já estamos projetando soluções baseadas no Vue.js na itexto).

Por falar em data binding, o modo como lida com formulários é também essencialmente o mesmo que temos no Angular.

Criação fácil de componentes

Assim como o Angular, o Vue.js também te permite criar componentes. No caso, o Vue é muito inspirado na spec Web Components do W3C. Note que é inspirado e não uma implementação desta spec.

A vantagem é que você pode escrever sua biblioteca de componentes reaproveitáveis com o Vue e, caso deseje abandoná-lo no futuro, o trabalho de reescrita (em teoria) deve ser bem menor.

Concluindo

Para situações nas quais só me interessa a renderização do lado cliente e a aplicação não é muito complexa (como o /dev/All), creio que Vue.js seja uma solução mais interessante que o Angular.

Se você ainda não o conhece, sugiro que leia seu guia e brinque um pouco com ele: é uma experiência muito interessante.  Na excelente documentação oficial há uma seção interessante na qual o comparam com outros frameworks, recomendo sua leitura, apesar de naturalmente se tratar de um texto tendencioso.

Creio que, apesar de ter preferindo o Vue, estudar Angular é essencial: tenho certeza de que boa parte da facilidade que tivemos em aprendê-lo (Vue) se deve aos conceitos que precisamos aprender em nosso estudo do Angular.

Se você gosta de vídeos, o Fabio Vedovelli tem uma série a respeito que vale muito à pena assistir (como tudo o que ele faz).

Modularizando JavaScript com Spring MVC e Jawr

javascript-logoEste post inicia uma série na qual vou expor técnicas que visam aumentar a manutenibilidade de código Javascript. Convenhamos: é uma linguagem de programação legal, porém muitas vezes o hype que a envolve nos impede de ver seus aspectos negativos. Neste post tratarei de uma das cicatrizes da linguagem que é a dificuldade que enfrentamos na modularização do código.

O problema: modularizar JavaScript usando Spring MVC

Se você tem a sorte de trabalhar com Grails tem à sua disposição uma solução maravilhosa que é o plugin resources que nos permite definir “módulos Javascript”. Infelizmente do lado Spring da cerca não temos algo tão popular. O que é um módulo Javascript?

Uma unidade de código que funciona em conjunto.

Muitas vezes esta unidade não é apenas um arquivo, mas vários, e é neste ponto que o problema começa a se manifestar. Imagine um módulo composto por dois arquivos: biblioteca.jsbiblioteca2.js. Sua equipe pode ter achado interessante dividi-lo em dois arquivos para paralelizar o esforço e com isto evitar todos aqueles incômodos relacionados ao merge de arquivos. Nesta situação, toda vez que você precisa usar este módulo, irá inserir em suas páginas código similar ao exposto a seguir:


<script type="text/javascript" src="/resources/js/biblioteca.js"></script>
<script type="text/javascript" src="/resources/js/biblioteca2.js"></script>

Ou então você poderia ter algum script que unisse os dois arquivos. O problema é que seria necessário modificar o seu processo de build e também fornecer garantias de que o arquivo gerado fosse sempre o mais atualizado possível (não é uma solução tãão bacana assim).

Agora, voltemos ao nosso exemplo. Imagine que este nosso módulo dependa do jQuery. Neste caso teríamos sempre de escrever o seguinte código em nossas páginas:


<!-- jQuery sempre irá ser carregado primeiro -->
<script type="text/javascript" src="/resources/js/jQuery.js"></script>
<script type="text/javascript" src="/resources/js/biblioteca.js"></script>
</span><script type="text/javascript" src="/resources/js/biblioteca2.js"></script>

Ainda pior: imagine que a ordem de carregamento dos arquivos biblioteca.jsbiblioteca2.js seja importante. Agora sua equipe precisa ser informada a respeito. Se for uma aplicação de uma única página, não será lá um grande problema, mas imagine uma aplicação maior, com mais de um template, etc. A coisa começa a se complicar.

A imagem a seguir expõe bem a situação do nosso projeto. Temos uma biblioteca composta por dois arquivos que depende de uma terceira:

jawr_dependencias

Não seria bacana se houvesse uma ferramenta que nos permitisse resolver os problemas a seguir de uma forma simples?

  • Documentar as dependências entre os nossos arquivos Javascript de tal forma que seja fácil para a equipe entender a organização interna do projeto.
  • Garantir que os arquivos sejam sempre carregados na ordem correta.
  • De alguma maneira otimizar o modo como estes arquivos são enviados ao browser: compressão via gzip, talvez até mesmo um merge dos arquivos.

Jawr entra em cena

logoJawr

Jawr é uma ferramenta que tem como objetivo resolver os três problemas que expus acima e mais alguns. Neste post irei tratar de uma parte bem pequena deste projeto: aquela que lida com Javascript. A grosso modo Jawr é um servlet que iremos inserir em nosso projeto fictício. Este servlet organizará nossos módulos Javascript em bundles.

O que é um bundle? É um módulo, tal como expus acima. Mais do que isto, um bundle alguns atributos fundamentais do nosso módulo:

  • Que arquivos compõem o nosso módulo
  • Em que ordem estes arquivos devem ser carregados
  • Quais as dependências do nosso bundle, isto é, que código este precisa para funcionar?

Voltando ao nosso projeto percebe-se que há dois bundles: biblioteca e jQuery, que podemos representar gráficamente tal como na imagem a seguir:

Nossos bundles

Nossos bundles

Poderíamos pensar em um bundle único composto pelos nossos arquivos da biblioteca e o do jQuery. O problema é que sabemos que jQuery será usado por diversos outros pontos da nossa aplicação: sendo assim é interessante que modularizemos esta parte a fim de que seja reaproveitada em outras partes do projeto.

Incluindo Jawr em nosso projeto

Nosso projeto é baseado em Maven. Sendo assim, para incluirmos o Jawr basta adicionar a dependência no arquivo pom.xml tal como no exemplo a seguir:

<dependency>
    <groupId>net.jawr</groupId>
    <artifactId>jawr</artifactId>
    <version>3.3.3</version>
</dependency>

Como disse logo acima, Jawr é essencialmente um servlet. Sendo assim temos também de alterar o arquivo web.xml para que fique similar ao exposto a seguir:

<!-- Servlet para lidar com Javascript -->
<servlet>
   <servlet-name>JavascriptServlet</servlet-name>
   <servlet-class>net.jawr.web.servlet.JawrServlet</servlet-class>

		<!-- Aonde se encontra o arquivo de configuracao -->
   <init-param>
       <param-name>configLocation</param-name>
       <param-value>/jawrJavascript.properties</param-value>
   </init-param>
   <init-param>
       <param-name>mapping</param-name>
       <param-value>/bundle/js/</param-value>
   </init-param>
   <load-on-startup>1</load-on-startup>
</servlet>
<!-- O mapeamento de URL -->	
<servlet-mapping>
   <servlet-name>JavascriptServlet</servlet-name>
   <url-pattern>/bundle/js/*</url-pattern>
</servlet-mapping>

Preste muita atenção no mapeamento de URL. Na documentação oficial do Jawr este é configurado para que lide com todos os recursos que terminem com a extensão .js. O problema com esta abordagem é que muitas vezes não queremos que todos os nossos arquivos Javascript sejam carregados como bundles. Talvez você queira ir adotando aos poucos a ferramenta em seu projeto (esta é a principal razão que vejo). Em nosso caso, Jawr só irá lidar com aqueles recursos Javascript que se encontrem na url /bundle/js/*. Nota importante: repare no parametro de inicialização mapping. Se for usar uma configuração como esta, este obrigatóriamente deve estar definido.

Configurando os bundles

No mapeamento do servlet foi incluído um parâmetro chamado configLocation. Em nosso projeto baseado em Maven este arquivo se encontra em /src/main/resources/jawrJavascript.properties. É neste arquivo que iremos definir todos os nossos bundles. Abaixo está um exemplo deste arquivo:

# Altere aqui caso esteja no seu ambiente de desenvolvimento
jawr.debug.on=false

# Devemos enviar os bundles compactados?
jawr.gzip.on=true

# De quantos em quantos segundos o servlet deve verificar se as configuracoes foram
# alteradas. Extreammente util em tempo de desenvolvimento!
jawr.config.reload.interval=30

# Primeiro bundle de exemplo: jQuery
# O identificador do bundle sempre é o que aparece antes do ‘.id’
# neste caso, é jquery
jawr.js.bundle.jquery.id=/bundle/js/jQuery.js
jawr.js.bundle.jquery.mappings=/resources/js/jquery-2.1.0.min.js

# Incluindo uma dependencia
jawr.js.bundle.biblioteca.id=/bundle/js/biblioteca.js
jawr.js.bundle.biblioteca.mappings=/resources/js/biblioteca.js, /resources/js/biblioteca2.js
jawr.js.bundle.biblioteca.dependencies=jquery

Um bundle Javascript é definido no arquivo com o prefixo jawr.js.bundle.[identificador do bundle]. A primeira linha, que termina com .id define como será a URL que define o nosso bundle. O bundle jQuery, por exemplo, sempre será carregado quando a URL /bundle/js/jQuery.js for acionada, enquanto o bundle biblioteca, pela URL /bundle/js/biblioteca.js.

Voltemos nossa atenção para o bundle biblioteca. A segunda linha da sua definição (mappings), define quais os arquivos que o compõe e a ordem na qual devem ser carregados. A terceira linha define quais as suas dependências. Neste caso, apenas uma: o bundle jquery.

Tendo feito isto temos todos os bundles em nosso projeto prontos para serem usados. O próximo passo é trabalhar no arquivo JSP.

Alterando o arquivo JSP

O projeto Jawr vem com uma biblioteca de tags bastante útil. Abaixo podemos ver um exemplo de sua aplicação:

<%– A declaração da biblioteca de tags –%>
<%@ taglib uri="http://jawr.net/tags" prefix="jwr" %>

<%– Carregando o bundle biblioteca –%>
<jwr:script src="/bundle/js/biblioteca.js"/>

E o que ocorre quando carrego a página? Obtenho o resultado a seguir:

<script type="text/javascript" src="/itexto/bundle/js/gzip_N1063700552/bundle/js/jQuery.js" ></script>
<script type="text/javascript" src="/itexto/bundle/js/gzip_N745101183/bundle/js/biblioteca.js" ></script>

Primeiro será inserida a dependência do bundle biblioteca e, em seguida, o código fonte do bundle biblioteca. Repare nas URLs: o Jawr irá automáticamente cachear os recursos Javascript. E sabem o que é mais legal? Ele também envia o Javascript comprimido (se o modo de depuração estiver desativado (veja as notas no arquivo que expus acima)). E não é só o conteúdo Javascript comprimido. Os dois arquivos que compõem o módulo biblioteca também são mesclados em um só, diminuindo assim o número de requisições necessárias. Simples assim. :)

Concluindo

Nese post apresentei uma pequena parte do projeto Jawr. Há mais neste servlet, que também pode ser usado para gerenciar recursos CSS e imagens. É importante salienar que a documentação do projeto é excelente: bem escrita e fácil de ser consultada.

Claro que a questão da modularização não termina aqui. Esta é apenas uma das soluções possíveis. Recentemente topei com um ebook online (e gratuito) chamado Writing Modular JavaScript with AMD, CommonJS & ES Harmony que trata da questão de uma forma muito mais profunda. Entra aí também o modo como escrevemos JavaScript (que não tratei neste post) e alguns outros pontos sobre os quais pretendo escrever mais a respeito em um futuro próximo.

O código fonte deste post pode ser acessado no meu GitHub: https://github.com/loboweissmann/jawr-testes

Por que resolvi largar o Flash e partir pro HTML 5 :)

HTML5_logo_and_wordmark.svgNada como algumas rotações da Terra pra mudar as coisas né? No dia 3/1/2010 publiquei aqui um texto chamado “Por que resolvi largar o HTML e partir pro Flash” que é um dos posts mais acessados deste blog desde então. Mas quando olho pro meu histórico percebo que na realidade nem deu tempo de largar o HTML 5 e a esmagadora maioria das frustrações que eu tinha com este até então não existem mais (aliás, nem sei se ainda restou alguma destas limitações).

Foi tudo muito rápido. No mesmo ano comecei o desenvolvimento de jogos em… HTML 5 usando canvas. Em dezembro eu já tinha uma versão do Space Invaders 100% canvas que também é outro post bastante popular aqui no blog. Fantástico né? Agora vamos voltar às minhas reclamações de três anos atrás.

O pesadelo do HTML (os tais “web standards”)

Na época se não me engano o grande problema era o Internet Explorer e a maior parte dos browsers não dava um suporte razoável aos novos recursos do HTML 5. Wow, como as coisas mudaram. Pra começar, hoje na média, de acordo com o site “Can I Use…” estamos com suporte de aproximadamente uns 80%, ou seja, basicamente apenas os recursos menos usados não são suportados pela maioria.

html5_support

Internet Explorer

E o Internet Explorer? Bom: ao menos no meu blog corresponde a bem menos de 10% dos acessos, mas neste caso não vale muito pois minha audiência é técnica. Mas tirando isto, vou usar uma fonte bem mais confiável. Atualmente corresponde a 15,6% de todo tráfego da Wikipédia.

O próprio Internet Explorer acabou melhorando bastante: a versão 10 possuí um suporte bem melhor e, além disto, pelo fato de a Microsoft ter adotado Javascript/HTML como sua plataforma de desenvolvimento preferencial (mesmo por que ao que tudo indica ninguém mais liga pro Windows) a coisa parece que vai ficar ainda melhor no Internet Explorer 11: ou ela se adapta ou tá fora, simples assim.

Como quase optei pelo Flash

Na época eu estava desenvolvendo um produto que era basicamente um kanban eletrônico (mas gostei tanto do Trello que acabei largando o projeto). Então basicamente era drag and drop o tempo inteiro na interface do usuário e o suporte que eu tinha no HTML 5 era bem fraco para alguns detalhes da interface. Além disto, a linguagem Action Script também tinha me fisgado: me apaixonei por ela conforme ia lendo mais a respeito.

Durante o desenvolvimento deste projeto meu interesse foi para a área de jogos: comecei criando algumas coisas com OpenGL (sim, existe um “Duke Nanna” em algum lugar aqui em casa) mas por algum acaso resolvi experimentar o canvas do HTML 5 (um experimento muito tosco me acordou). Boom! De repente as coisas que eu achava serem possíveis apenas no Flash eu estava conseguindo com Javascript! Logo em seguida vieram animações com CSS 3, suporte a persistência local, dados de localização e pronto: em algo tipo seis meses eu já podia fazer práticamente tudo o que o Flash oferecia sem precisar comprar uma licença do produto.

O suporte que os navegadores passaram a oferecer a estas tecnologias veio muito rápido, bem mais rápido do que eu esperava (no post eu falo algo sobre o HTML 5 só estar pronto em 2022). Erro meu, que bom! :)

A presença “universal” do Flash

Eu realmente acreditava que só a Apple iria chutar o Flash e com o tempo acabaria voltando atrás. Wow, como estava errado! Na realidade diversos players começaram a simplesmente abandonar a plataforma por completo. Meu celular atual (um Nokia Lumia 800 com Windows Phone 7.8) já apresenta dificuldades ao lidar com o formato, idem para diversos dispositivos Android. Dado que mobile, e não desktop é o futuro, Flash não está mais com os dias contados, pois simplesmente não há mais dias para contar: acabou.

E ei: a popularização de coisas como Phone Gap e Appcelerator também contribuiram muito pra isto. De repente estamos criando aplicações semi nativas mobile usando HTML 5. Mais um prego no caixão.

Concluindo

Bendito seja o dia em que resolvi brincar com o canvas! Até então eu não conseguia ver o potencial da plataforma que estava surgindo (ela realmente se mostrava muito débil pra mim). HTML 5 pode até não ser oficialmente um padrão hoje, mas na prática é: e ao que tudo indica vai ser o padrão durante os próximos anos e talvez das próximas décadas.

O proprietário vai aos poucos sendo enterrado e o aberto dominando. Me pergunto: visto que esta plataforma está dominando de tal forma, será que aquele velho sonho de tornar o sistema operacional mero comodite já está se concretizando? Será que poderemos dizer em pouco tempo que tanto faz você ter um Mac ou PC pois sua aplicação foi feita pra rodar inteiramente na web? Acho que sim: mas ainda vai demorar um pouco.

PS: daqui a três anos eu volto a este post pra ver o quão certo ou errado eu estava ok?

Trazendo o Atari para o HTML5 com Canvas: Space Invaders

Continuando minha pesquisa sobre HTML5 usando canvas, aqui está meu mais novo experimento: recriei à minha moda o clássico “Space Invaders” do Atari. Confesso que fiquei MUITO satisfeito com o resultado e, espero, vocês também.

Desta vez não posso dizer que o código seja tão mínimo quanto minha primeira grande experiência, pois um dos meus objetivos foi justamente trabalhar em algo mais complexo. Sendo assim, para evitar ficar perdido em uma multidão de código fonte, optei por modularizar meu projeto.

Há algumas diferenças com relação ao original que devem ser salientadas:

  • O jogo possui final: basta aniquilar todos os invasores para ser saudado com os meus “peculiares parabéns” :D (fica a surpresa). Há somente um nível.
  • Não há barreiras de proteção, o que torna o jogo mais difícil e, na minha opinião, mais divertido também.
  • A coreografia dos invasores está ligeiramente diferente (gera uma certa confusão que me diverte bastante)
  • E, claro, eu vou te xingar o tempo inteiro :D

É importante mencionar que, novamente, é apenas uma prova de conceito. Estou evoluindo aos poucos para que, em um futuro que espero próximo, eu possa desenvolver coisas mais complexas usando tanto HTML5 como outras tecnologias (Flex, OpenGL, Java, etc.). Pra mim, é muito mais uma saída da minha zona de conforto. Saida esta que tem me feito MUITO bem (e eu recomendo a todos).

Sobre compatibilidade entre browsers

Novamente, o browser campeão foi o Chrome. Ele renderizou tudo perfeitamente sem problemas e, o que achei mais interessante: também reproduziu meu áudio perfeitamente. Pra minha surpresa, ele aceitava o formato MP3, que foi aonde gravei os sons pela primeira vez. No Firefox, no entanto, eu só posso tocar arquivos no formato OGG ou WAV (fiquei com preguiça de converter, sendo assim, para ouvir minha voz sexy, use o Chrome), porém a renderização no Firefox, assim como no Chrome, é perfeita.

No IE8 o “Space Invaders” simplesmente não executou. Sinceramente, nem me esforcei neste caso, porque, confesso, tenho birra deste browser (como todos vocês).

Minha grande decepção desta vez foi o Safari. Como não estou com meu macbook, tive de testar meu jogo na versão Windows, e por alguma razão, caso você morra ou termine o jogo, ele trava. Ao usar as ferramentas de desenvolvimento, fiquei muito frustrado, pois elas não me permitem depurar o código tão bem quanto no Chrome ou no Firefox usando Firebug.

Resultado final

Basta clicar na imagem abaixo para ver o resultado. Espero que se divirtam jogando-o (e fuçando meu código) tanto quanto eu AMEI trabalhar nesta brincadeira. Semana que vêm coloco mais uma aventura por aqui.

Levando o Atari para o HTML5 usando canvas e Javascript – Freeway

Em 1985 ganhei meu primeiro video game do meu pai: era um Atari 2600, e o jogo que o acompanhava era o “Freeway”. Sendo assim, nada mais natural que o primeiro jogo que eu tente recriar seja este!

Me propus recriar em Javascript usando o novo elemento canvas presente no HTML 5 alguns clássicos do Atari (de preferência, todos). Optei pelo Atari pelas seguintes razões:

  • São jogos extremamente simples do ponto de vista gráfico (basicamente, apenas desenho de retângulos e pouquíssimas transformações)
  • As regras são banais. Veja Freeway, por exemplo: tudo o que você precisa fazer é levar a galinha ao outro lado da rua para que, por mágica, mais uma tente a mesma travessia.
  • O desafio técnico é do caralho: basta lembrar que River Raid, com seu mapa de proporções quase infinitas ocupava APENAS 4 KB de memória.
  • O Atari possui um valor muito especial pra mim. Foi meu primeiro videogame e, além disto, o dispositivo no qual desperdicei minha infância. :D

Esta minha primeira versão do Freeway é apenas uma prova de conceito. Antes que postem aqui os defeitos, os listo para vocês:

  • Meu algoritmo de colisão é muito fraquinho. Basicamente, os carros só tem a certeza de terem aniquilado nossa pobre galinha quando passam por cima da sua cabeça
  • As ruas são ainda mal desenhadas – eu poderia melhorar isto, mas quer saber? Fiquei com preguiça. :D
  • Ainda não domino bem a escrita de texto com o canvas. Repare como os textos aparecem horrívelmente borrados.
  • A renderização, como já se era de esperar, varia um pouco entre navegadores. No caso, testei o Freeway apenas no Firefox 3.5 e Chrome.
  • Ainda não há som (não trabalhei neste ponto ainda)
  • Só há uma galinha! (esta é uma prova de conceito meu caro!)

Clique no screenshot abaixo para tentar ajudar nossa pobre galinha a atravessar a rua. (e divirta-se com meu código fonte!) :D

Conclusões após o experimento

Javascript está se tornando, pouco a pouco, minha linguagem favorita. O ambiente de desenvolvimento é o que mais gosto: apenas um editor de texto e um browser, nada de IDEs (nada contra IDEs, mas adoro este sentimento de “raiz”). No caso do Freeway, o desenho é basicamente bitmap, ou seja, são criadas matrizes com valores numéricos represenando cores que em seguida são renderizadas, como quadrados adjacentes na tela. Bem simples.

Freeway foi o primeiro e último jogo de Atari que criei “na unha”. A partir deste primeiro trabalho, iniciei o desenvolvimento de uma biblioteca que me permite automatizar diversos elementos presentes em um jogo, como por exemplo renderização, física, inputs, etc. Nesta biblioteca há, por exemplo, um editor gráfico (tudo é escrito em Javascript) que me permite criar sprites muito mais rápido que o método aplicado em Freeway (to louco pra liberar este subprojeto).

Óbviamente, eu poderia ter implementado um Freeway muito melhor em C ou Java, mas quer saber? Estou descobrindo até onde posso ir no canvas. E até agora, poucas limitações apareceram (99% fruto da minha própria ignorância). Faz muito tempo que não me sinto tão feliz aprendendo algo. Espero que gostem da minha versão do Freeway. Aguardo opiniões!

Grande abraço!

PS: Ah! Como no original, a galinha só pode se mover pra cima e pra baixo. :D

Brincando com canvas/HTML5

Tenho um brinquedo novo agora: trata-se do elemento canvas presente no HTML 5 e atualmente suportado por práticamente todos os browsers modernos (há uma lista de compatibilidade aqui). Bem: meu objetivo para 2011 é começar a atuar profissionalmente com jogos. Sendo assim, comecei com OpenGL e SDL, que estou estudando frenéticamente. Porém, vi alguns demos usando canvas e pensei: “ei! Quero fazer também!”.

Sendo assim, neste post vou expor três experimentos que fiz com este novo recurso do HTML 5. Em um post posterior, pretendo explicar o código fonte de cada um deles.

Experimento 1: Nanna Invaders

Essa Nanna… vive aprontando das suas! Neste experimento, tentei criar um jogo bem simples. A regra é besta: você deve destruir os terríveis invasores retangulares que tentam destruir a Terra. Esquerda e direita para movimentar-se, direcional pra cima para atirar. Não ligue para os gráficos (foi o meu primeiríssimo experimento, e ainda está portanto “atarístico”).

Experimento 2: Dilúvio de Papel

Após criar interatividade bem básica com Nanna Invaders, resolvi fazer experimentos estritamente gráficos. A idéia era ver o que eu poderia fazer usando, além das primitivas gráficas do canvas, as transformações também. Dilúvio de Papel é basicamente a aplicação da transformação rotação em “nuvens” que havia desenhado anteriormente.

Para minha surpresa, o resultado foi incrívelmente agradável. Diria até hipnótico. :)

Experimento 3: Fantasmas

Resolvi então ir um pouco além. Que tal criar personagens mais simpáticos que um retângulo? Foi quando surgiram fantasmas em minha cabeça. :)

Conclusões até agora

Ainda estou no início do aprendizado, mas o que pude observar é que trabalhar com canvas é muito mais fácil do que imaginava e, pra minha surpresa, a compatibilidade atualmente está bem boa. Vi minhas animações sendo executadas muito bem, com diferenças perceptíveis mas mínimas no IE8, Firefox 3.5 e Chrome (no Chrome o bicho BRILHA).

Outro ponto que me chamou a atenção foi a quantidade de código que precisei digitar. Repare no código fonte (é o que há de realmente bonito nestes experimentos). Ele é mínimo!

Já li alguns posts dizendo que o canvas irá matar o Flash. Minha opinião é que, ao menos no momento, isto é papo furado. O “animador” precisa saber programar e nem sempre (na realidade, quase nunca), este possui boas habilidades de desenho. Arrastar e soltar ou desenhar usando o mouse com o canvas ainda é sonho. Só vejo o canvas chegar próximo ao Flash se um dia surgir alguma IDE bacana (e esta, acredito, vai ser da própria Adobe :) ).

Por enquanto, é isto. Nas próximas semanas pretendo publicar mais alguns experimentos nos quais venho trabalhando (incluindo detalhes sobre o funcionamento). Estou MUITO animado com os resultados (ainda não publicados). E você? O que achou dos meus bichinhos?