Joel Webber, um dos criadores do Google Web Toolkit (GWT), apresentou a palestra Angry Birds on HTML 5 no evento GOTO Aarhus 2011, disponível no InfoQ norte-americano. Entrevistamos Webber para saber mais detalhes sobre a transformação do Angry Birds para HTML5.
InfoQ: Fale-nos sobre os detalhes técnicos da portagem do Angry Birds para o HTML5
Joel Webber: Resumindo, o jogo é escrito em Java e então é feita a compilação para JavaScript usando o Google Web Toolkit. Durante o processo de conversão, escrevemos uma pequena biblioteca chamada PlayN, que permite ao desenvolvedor de jogos trabalhar totalmente em Java e fazer a depuração diretamente na JVM (isso oferece muito mais recursos do que a depuração no navegador). A biblioteca PlayN também permite fazer uma compilação cruzada para execução em Flash e Android, embora a Rovio [empresa criadora do Angry Birds] não utilize esta funcionalidade atualmente.
InfoQ: Quais funcionalidades do HTML5 foram usadas?
JW: Algumas das tecnologias usadas não são tecnicamente "HTML5", embora sejam muitas vezes referidas como tal. Uma lista resumida é: WebGL, Canvas, CSS3 (especialmente transformações afins), LocalStorage e <audio>/WebAudio. Para renderização, usamos dois modos: WebGL e DOM.
No modo WebGL, há basicamente um grande elemento <canvas> na pagina. No modo DOM, usamos um elemento DOM diferente para cada objeto (pássaro, porcos, blocos, elementos de fundo etc.), então usamos as transformações do CSS3 para posicioná-los de forma eficiente. A razão para esta separação é que há muitos navegadores que ainda não suportam o WebGL e queríamos garantir que o jogo funcionasse em todos os navegadores possíveis e não apenas no Chrome.
Para áudio, precisamos usar inicialmente uma alternativa baseada em Flash, porque o suporte para a tag <audio> era limitado na maioria dos navegadores (incluindo o Chrome). Isto foi corrigido desde então, e agora o Flash é usado apenas como solução alternativa, raramente usada. No final, consideramos que o WebAudio é a API correta para a criação para jogos.
InfoQ: Quanto esforço foi necessário para portar o jogo?
JW: É difícil dizer com precisão. Havia três engenheiros do Google fornecendo suporte para a Rovio, mas isso normalmente acontecia no nosso "tempo 20%" (e em algumas noites e finais de semana). Um engenheiro da Rovio fez a maior parte do trabalho de conversão; outros vieram depois para ajudar com coisas como pagamentos dentro da aplicação e questões de produção.
InfoQ: Qual foi a parte mais difícil?
JW: O porte da lógica do jogo foi bastante simples. Já tínhamos trabalhado no porte do Box2D (o mecanismo de física usado pelo Angry Birds e por muitos outros jogos com física 2D). E escrever o jogo em Java facilitou o gerenciamento do código, que é bastante extenso. Mas algumas coisas exigiram trabalho adicional:
- Carregamento de recursos: Diferentemente da maioria das aplicações nativas, uma aplicação web geralmente carrega seus recursos sob demanda, para que seja inicializada mais rapidamente. Isto é normalmente positivo, mas deixa a lógica da aplicação mais complexa, porque é preferível mostrar cada tela do jogo assim que os recursos correspondentes são carregados. Isto também significa que é preciso ter cuidado com a ordem em que os recursos são requisitados, para não desperdiçar banda de rede com itens que não são necessários no momento.
- Renderização em vários navegadores: Não há uma "melhor" maneira de renderizar os gráficos do jogo em todos os navegadores; por isso tivemos bastante trabalho para abstrair a renderização e implementar duas abordagens muito diferentes.
- Ter o jogo rodando suavemente, com 60 quadros por segundo, foi um objetivo muito importante. As pausas para coleta de lixo criaram dificuldades, mas conseguimos resolvê-las no final.
Na apresentação no InfoQ.com, Webber oferece mais informações sobre as dificuldades com a coleta de lixo, e detalhes sobre a biblioteca PlayN e o seu papel na depuração na JVM.