Quake II portado para HTML5

Em novembro do ano passado, eu disse que era questão de tempo para que isso acontecesse. Também em novembro, Joel Webber, um engenheiro do Google, teve a inspiração de portar Quake II para o HTML5 a partir do Jake2 – um port Java do jogo – usando o Google Web Toolkit, que permite que aplicativos como o Google Mail, o Google Maps e o Google Wave sejam criados em Java e compilados como JavaScript. Ao lado de dois engenheiros do Google (Ray Cromwell e Stefan Haustein) que colaboraram “em 20% do tempo”, a ideia deu certo!

Como isso funciona?

O “GWTQuake” pegou o Jake2 e o botou para rodar no Google Web Toolkit (um framework e compilador para a criação de aplicativos web em java), convertendo-o em JavaScript e em uma coleção de elementos Canvas, Audio e Video do HTML5. O Jake2, por sua vez, depende de várias interfaces Java que não estão presentes diretamente no GWT e nem no navegador, especialmente nas áreas de rede, teclado e entrada e saída de arquivos. Joel teve que implementar novos mapeamentos para que o código em Java correspondesse às tecnologias dos navegadores. Por exemplo, o Java usa entrada e saída assíncronas, mas o JavaScript é movido a eventos (onekeyup, onekeydown etc). “Stefan Haustein contribuiu com novas classes do JRE para implementar o Buffer NIO do Java com base nos novos arrays tipados do JavaScript, bem como com um renderizador GL baseado no WebGL.”

O WebGL é uma tecnologia experimental, que visa trazer o 3-D para os navegadores usando o OpenGL ES, versão reduzida do OpenGL feita para dispositivos embarcados (o iPhone, por exemplo, usa o OpenGL ES 2.0 como API 3-D). Tanto o Firefox quanto o WebKit/Chrome, em suas versões de desenvolvimento mais recentes, oferecem suporte ao WebGL, mas pode demorar um pouco para que essa tecnologia esteja apta a integrar uma versão estável (a especificação ainda está sendo desenvolvida, sua última versão preliminar foi publicada em dezembro de 2009).

O WebGL está centrado no elemento Canvas do HTML5, que proporciona um contexto de renderização no qual é possível desenhar com JavaScript. Com ele, as páginas web podem renderizar imagens pixel por pixel. O Canvas foi inventado pela Apple para ser usado nos widgets do Dashboard do Mac OS X Tiger. De lá para cá, o elemento foi adotado e padronizado pelo grupo que trabalha no HTML5. O Firefox, o Safari, o Chrome e o Opera são compatíveis com ele. Não se sabe ainda se o IE9 também vai ser, embora o suporte a outras tecnologias do HTML5 como os elementos Video e Audio estejam prometidas.

Outra tecnologia interessante do HTML5 usada aqui é a dos WebSockets. Eles dão ao navegador a capacidade de abrir uma conexão TCP de duas vias com um servidor em um canal de comunicação. Esta é uma melhoria em relação ao AJAX, que é uma tecnologia síncrona de alta latência e muito mais robusta do que o “Comet”, um hack que faz o AJAX atuar de forma mais assíncrona. Usando WebSockets, o navegador pode canalizar dados nos dois sentidos em alta velocidade, mais próximo do comportamento de um aplicativo nativo. No caso, o GWTQuake usa WebSockets para criar a rede entre o cliente e o servidor, e com isso o GWTQuake pode até ser jogado em modo multiplayer! WebSockets, como o WebGL, no momento só são compatíveis com as versões de desenvolvimento do Safari, do Chrome e do Firefox.

Para carregar e salvar jogos no GWTQuake, é usado o armazenamento local do HTML5: são pares chave:valor usados por aplicativos web para armazenar mais dados do que o possível com cookies. O Google usa esse armazenamento no GMail Mobile para fazer cache e oferecer acesso offline aos dados. Ao contrário do que acontece com os cookies, os dados não são enviados para o servidor a cada solicitação, e persistem depois que os cookies são apagados. Sendo assim, não é preciso fazer download ou upload de arquivos para carregar o jogo no GWTQuake, basta abrir a URL e escolher “load” (carregar) no menu!

Como eu jogo isso?

No momento, o GWTQuake, é preciso baixar e compilar o código fonte no site do projeto no Google Code. As ferramentas OGG Vorbis e Lame são necessárias para que os dados do Quake2 sejam convertidos em vídeo OGG e em áudio MP3, usados no navegador.

Há diversos problemas, que variam de acordo com sua plataforma, mas consegui compilar estas instruções para o Mac OS X a partir de comentários feitos por terceiros sobre as instruções fornecidas pelo Google.

1. Instale o HomeBrew para obter o Vorbis e o Lame (e o Mercurial) com facilidade
   (estas instruções foram fornecidas por “64.brian”):

   sudo chown -R $USER /usr/local

   curl -Lsf http://github.com/mxcl/homebrew/tarball/master | tar xvz -C/usr/local –strip 1

   brew install vorbis-tools

   brew install lame

   #caso você não tenha o Mercurial
   brew install pip && pip install mercurial

2. Checkout do código fonte do GWTQuake (exige o Mercurial):

   hg clone https://quake2-gwt-port.googlecode.com/hg/ quake2-gwt-port

   Nesse momento, você pode ter que dar um “cd” para entrar no diretório quake2-gwt-port.

3. O Maven acusou falta de memória ao compilar o código fonte no OS X, para resolver é só usar o comando (instruções fornecidas por “redchris”):

   export MAVEN_OPTS=-Xmx512m

4. Compile, baixe o demo de Quake2 e rode o servidor:

   ./build-dedicated-server
   ./install-resources
   cp -r maven-build/server/target/gwtquake/war/gwtquake war
   ./run-dedicated-server 8080

5. Rode o jogo abrindo http://localhost:8080/GwtQuake.html no navegador!

Compatibilidade com navegadores

No momento, o GWTQuake só funciona em versões de desenvolvimento do WebKit ou do Chromium. Lamento, ainda não há suporte ao Firefox. Parece que faltam alguns recursos necessários (sei que o Firefox é compatível com WebGL, WebSockets e em teoria tudo o que é necessário, mas sem depurar o programa por conta própria não consigo descobrir qual é o problema).

A página de compatibilidade de navegadores do Google tem links para o WebKit e o Chrome, e ainda indica os comandos a executar para habilitar o WebGL (que vem desativado por padrão nos dois navegadores).

Além disso, o Chrome precisa ser executado sem o recurso de sandboxing, do contrário vai ficar muito lento devido ao tempo gasto na cópia do framebuffer entre os processos.

Outro problema sério é que na maioria dos monitores a imagem fica bem escura. Isso acontece porque o jogo original fazia ajustes de gamma (luminosidade) nas texturas durante o carregamento, e esse comportamento não foi portado para o GWTQuake por questões de desempenho (consulte o FAQ).

Nas fotos deste artigo eu defini o gamma da tela como 1.2 para as imagens ficarem mais visíveis.

E o jogo roda bem?

Incrivelmente bem, se levarmos em conta que roda no navegador! Mas há vários bugs. Quando o jogo é carregado, só aparece uma tela preta no Chrome, e o texto do console fica se sobrepondo. Basta apertar enter para que o menu apareça.

Uma coisa legal no fato do código rodar na web é que os dados são carregados de forma assíncrona. Quando você começa um jogo, as texturas são exibidas quase que da mesma forma que imagens em uma página comum!

No WebKit, objetos como armas, inimigos e outros com os quais podemos interagir piscam um pouco. No Chrome eu fiquei sem som, mas os objetos não piscavam.

O WebKit acusava entre 7 e 10 quadros por segundos, mas francamente o jogo me pareceu estar rodando bem mais rápido do que isso (talvez perto dos 20 quadros por segundo). No Chrome, a coisa ficava entre 1 e 2 FPS. Ray Cromwell disse que “No WebKit/Chrome eu chego a ter entre 20 e 25 quadros por segundo em um MacBook, e 45 quadros por segundo no meu desktop Mac Pro. Segundo Joel, um notebook com Linux bate nos 60 quadros por segundo”.

A mira fica meio bagunçada quando o mouse escapa da janela do navegador, e quem quiser jogar de verdade vai ter que jogar com tela cheia.

É claro que temos que ter em mente que esta versão de Quake II é altamente experimental e não muito otimizada. O FAQ observa que:

O código original de Quake II foi criado diretamente em C, no meio dos anos 90. O port Jake2 para Java foi bem direto, preservando a maioria das particularidades do C, incluindo pilhas gigantes de métodos estáticos no lugar das funções do C. Além disso, hackeamos o código para que ele funcionasse e fosse razoavelmente otimizado, mas obviamente isso teve alguns efeitos colaterais.

Levando-se em conta que o jogo foi compilado para JavaScript a partir de código Java que estava longe de ser ideal, o desempenho é impressionante. Se o jogo tivesse sido escrito do zero em JavaScript (ou melhor ainda, usando o Native Client), acho que o desempenho ainda seria bem melhor.

O que isso significa?

Que você não deve presumir que o navegador só serve para exibir documentos, ou que ele ainda é tão lento e incapaz quanto antigamente.

Mas tenha em mente que todas as tecnologias em uso aqui ainda estão em franco desenvolvimento. Acho que vamos esperar uns dois anos para que essa tecnologia e os jogos que fazem uso dela cheguem ao público em versões estáveis do Safari, do Chrome e do Firefox.

Para os usuários, a longo prazo, essa tecnologia é uma grande simplificação, e remove muitas barreiras. Temos aqui um jogo 3-D, e basta acessar uma URL para jogá-lo. Nada de downloads, nada de instalação. Você “instala” o jogo marcando-o em seus favoritos. Simples assim. As URLs podem ser montadas para apontar para salas específicas em sessões de multiplayer, e você pode convidar seus amigos para entrarem em um jogo que esteja em andamento simplesmente mandando a URL por email, pelo mensageiro instantâneo ou pelo Twitter!

Tem havido um grande debate quanto à rivalidade entre o HTML5 e o Flash, especialmente com o lançamento iminente do iPad (que, apesar das queixas de alguns, não parece estar tendo problemas para fazer com que usuários pesados do Flash migrem para o HTML5). Embora o HTML5 ainda não possa substituir completamente o Flash, os recursos estão aparecendo, e vão permitir que ele vá além do que é possível no Flash. A Mozilla fez uma demonstração do WebGL rodando no Nokia 900; ela optou por desabilitar o Flash por padrão no Firefox Mobile, declarando que “O plugin do Flash da Adobe usado em muitos sites prejudica o desempenho do navegador ao ponto dele não atender aos nossos padrões”.

A Adobe prometeu melhorias no desempenho do Flash 10.1, mas isso não vai mudar o fato de que nem o iPhone nem o iPad incluem o Flash. Depois de criar conteúdo adotando padrões oficiais para que esse conteúdo rode no iPhone e/ou no iPad, porque um desenvolvedor iria querer refazer tudo em Flash para os usuários de desktops?

O Quake II em HTML5 não existe para ser um exemplo real dessa tecnologia. Ele serve para inspirar os desenvolvedores a ultrapassarem os limites do que se presume que os navegadores possam fazer. É possível disponibilizar jogos e experiências gráficas atraentes usando apenas um URL, com toda a liberdade proporcionada pela rede (em oposição à App Store, por exemplo), para vários sistemas operacionais, plataformas e processadores. Podem se passar anos até que essa tecnologia chegue a todos os dispositivos, e muitos outros anos para que ferramentas de desenvolvimento sejam disponibilizadas a programadores de todos os níveis de habilidade; mas isso vai acontecer mais cedo ou mais tarde, porque a internet é o novo sistema operacional.