Proyecto Picross: haciendo un videojuego HTML5 en Dart

Ya lo dije en mi anterior entrada sobre el lenguaje Dart: Dart está muy bien, puede suponer una revolución en la web y su futuro potencialmente es muy prometedor. Pero claro, una cosa es el posible futuro y otra es el presente. ¿Cuál es realmente el estado actual de la plataforma Dart?.

Por otra parte, otra tecnología que me llama la atención es la de los videojuegos HTML5. Sobre todo para videojuegos 2d, sencillos, que aparentemente ya deberían poder hacerse en la web. Con la gran ventaja de ser multiplataforma, que se puedan jugar en Android, en iOS, o hasta desde el Facebook, y en este último caso sin tener que instalar nada. ¿Están estas tecnologías suficientemente maduras?.

Con ánimo de comprobarlo y a la vez divertirme, me lié la manta a la cabeza, uní las dos inquietudes y me puse a hacer ¡un videojuego en Dart!. Y aquí cuento todo el proceso, que duró sólo una semana, pero que me dio para asistir a la Gameme5  e incluso participar en la PiWeek.

La GameMe5

Yo de videojuegos en HTML5, la verdad, ni idea. Afortunadamente, estaba apuntado a la GameMe5, un evento organizado por HTML5 Spain y Wimi5 en el que ofrecían un taller de programación de videojuegos en Javascript el Viernes y varias charlas el Sábado.

El taller lo daban Carlos Benítez (@EtnasSoft) y Sergio Ruiz (@serginator), y en él fueron explorando un juego que se habían currado aposta y que era muy muy completito, desarrollado enteramente en Javascript a pelo y sin librerías.

Fueron avanzando poco a poco en el desarrollo y cubrieron muy bien muchos aspectos del desarrollo de videojuegos en general y de Javascript en particular, desde los temas más básicos como el loop principal y el doble buffer hasta otros más complejos como las rotaciones, los fondos por trocicos (en mosaicos), los métodos de detección de colisiones, algoritmos de búsqueda (pathfinders), manejo de física y sistemas de partículas. Lo mejor del taller es que aparte de estos aspectos más o menos generales de los videojuegos, iban comentando también temas de rendimiento y problemas de Javascript. Dijeron que un buen juego JS puede llegar a estar a la altura de un juego de PS2, si es 2d, o entre PS1 y PS2, si es 3d. Pero además comentaron problemas que tenían los navegadores si querían hacer efecto espejo automáticamente en las imágenes, usar base64 o como no tuvieran cuidado con los arrays y el recolector de basura (al eliminar un elemento de un array no lo elimina de verdad, sino que lo deja pendiente de GC, lo cual puede llegar a causar un parón sensible en un videojuego).

En las charlas del día siguiente hubo de todo, pero me gustaría destacar sobre todo 3 que fueron especialmente interesantes. En la primera, José Javier García-Aranda de Alcatel-Lucent hablaba sobre un algoritmo en el que están trabajando para compresión de imágenes y vídeo, LHE (Logarithmical Hopping Encoding), y que puede ser muy potente para el Cloud Gaming y las videoconferencias, ya que se consiguen tiempos de codificación rondando los 2ms y una calidad decente a 0,1 bits por pixel. Fue una de esas charlas que destacan porque lo que se cuenta es muy interesante, se entiende muy bien y además el ponente es muy ameno.

En la segunda Jorge del Casar (@jorgecasar) hablaba sobre WebSockets, y nos hacía una demo con un Tetris multi-jugador.

Y por último Imanol Fernández (@MortimerGoro) de Ludei nos daba una apabullante lección sobre rendimiento de Javascript, haciendo una demostración de un pequeño programa que tardaba 600 veces más en su versión Javascript que en la versión C++, y luego le aplicaba muchos trucos hasta conseguir que fuera "sólo" 6 veces más lenta. Sobre todo se usaron técnicas para conseguir que el compilador JIT de Javascript hiciera "inline caching" de las funciones más importantes, ya que es muchísimo más rápido, con cosas tan aparentemente absurdas como borrar un comentario o borrar un try-catch. Por ahí rondaron conceptos como las "hidden classes" (que se crean cuando añades atributos nuevos en tiempo de ejecución, y que ralentizan bastante) y arrays de más de 64K (leeentos). Pero vamos, si os interesa el tema, lo mejor es que veais la presentación completa.

Aparte de eso, también nos habló de CocoonJS, una herramienta que ha hecho que permite publicar tus videojuegos HTML5 en móviles, pero que al contrario que Phonegap, en lugar de utilizar los browsers que vienen de serie en las respectivas plataformas, utiliza uno propio, con su propia implementación de canvas, audio, webGL, etc., y con un rendimiento optimizado respecto a los otros (are we crazy? yes, but we're from Bilbao). La verdad es que tenía una pinta tremenda.

El videojuego: Picross

La verdad es que la GameMe5, en la práctica, sirvió a mi proyecto sobre todo para una cosa: acojonarme. Tanta optimización, tanto comportamiento extraño de los motores JS, tanto lío con los navegadores, tanta facilidad para quedarse sin memoria... y voy yo y le meto una capa más de riesgo por encima, Dart.

Así que decidí que ya tenía bastante cubierto mi cupo de riesgo y decidí hacer un juego sencillito, que no requiere gran rendimiento pero que a la vez escala muy bien, y da para ir añadiéndole cositas poco a poco. Y por supuesto, ¡muy divertido!.

Picross es un juego de tipo puzzle que se conoce por muchos otros nombres de los cuales el parecer el más oficial es "nonogramas".  Habrán salido millones de versiones del juego, tanto para ordenador como en papel, pero la que se hizo más famosa en su día fue la versión de Nintendo DS, o al menos esta es la que yo conocía y de la que me vicié hace años. Como buen juego de puzzles, se puede dejar el rendimiento un poco de lado y que siga siendo jugable, y eso es lo que a mi me importaba llegado a este punto. Sobre todo, porque tenía que tener una versión presentable en una semana, ya que me había presentado a la PiWeek.

El funcionamiento del juego es sencillo: hay una matriz de celdas, y cada una de ellas es un píxel, que puede ser blanco o negro. Todas juntas forman un dibujo binario que es el que hay que averiguar. Para hacerlo, cada fila y cada columna tienen una serie de números que indican los grupos de píxels negros que son consecutivos. Por ejemplo, si en una fila pone "3 2" significa que hay 3 píxels negros seguidos y luego separados otro grupo de 2 píxels negros. Entre medias, antes y después, hay un número indeterminado de píxels blancos. Combinando las pistas de las filas y las columnas, se va averiguando el dibujo.

La PiWeek

Kaleidos es una empresa de desarrollo que probablemente pueda presumir de tener el mayor ratio de densidad de geeks por metro cuadrado en toda España. Se definen como una empresa orientada a proyectos de innovación, así que tienen varias iniciativas muy interesantes orientadas a la innovación y la mejora. Una de ellas es la PiWeek ("Pi" de "Personal innovation"), una semana entera en la que paran por completo todos los proyectos que estén haciendo en ese momento para hacer... lo que le dé la gana a cada uno. Así, tal cual, lo que sea que le interese. Las únicas reglas son usar software libre para el desarrollo, y tener algo enseñable para una demo el Viernes.

La PiWeek tiene vocación abierta, y por tanto admite gente que no sean empleados de Kaleidos, ya sean individuos o empresas. El caso es que a mi me quedaba todavía una semana de vacaciones, sin ningún plan concreto, y de hecho tenía pensado dedicarla a este proyectillo, así que, ¿por qué no presentarme a la PiWeek, y así por un lado obligarme a hacer algo y por otro poder compartir proyectos con más gente?. Dicho y hecho, el Viernes anterior a la PiWeek se presentan propuestas de proyectos para formar equipos... y allí estuvo Picross.

Yo ya conocía a unos cuantos de Kaleidos, sobre todo a través del grupo de usuarios de Groovy Madrid GUG, pero la semana me dio la ocasión de charlar con todos, y la verdad es que es una gozada, en general son gente muy preparada y sobre todo derrochan pasión por la tecnología y el desarrollo. Entre los proyectos que se presentaron a la PiWeek había algunos como un clon de Twitter usando Redis y Spring integration, un visor de comics Android con detección de viñetas, un plugin de Chrome capaz de capturar pantallazos como GIF animados, un traductor de Python a Javascript (bautizado como CobraScript) o un aplausómetro hecho en Arduino, junto a otros más... rarunos, como un MUD hecho en Eiffel o una librería que permite crear parsers en Clojure. Salieron un montón de proyectos, pero todos tenían algo que contar. El ambiente que se crea durante la PiWeek es impresionante.

Haciendo el juego

Y llegó el momento de ponerse con el juego. Las primeras sensaciones con Dart son muy buenas, no es un lenguaje ni unas herramientas a las que estés acostumbrado, no son ni mucho menos tu "zona de confort", pero tanto las herramientas como el lenguaje y las librerías resultan cómodos e intuitivos. Esperaba encontrarme con alguna característica del lenguaje que echara de menos (el típico "no me puedo creer que esto no exista aquí"), pero no encontré ninguna.

Integración de Dart con Javascript
Mi primera intención era hacer un interfaz Dart para una librería Javascript de videojuegos. Después de estar echando un vistazo a unas cuantas me decidí por MelonJS, ya que había oído hablar bien de ella y era más pequeña y ligera que otras como Cocos2D. Después de varias pruebas básicas que aparentemente funcionaron, fui creando clases "proxy" que intermediaran con la librería, usando sólo lo que iba necesitando... hasta que de repente una prueba, justo después de haber hecho un montón de código, dejó de funcionar.

Tras un rato pegándome con ello, descubro que no podía llevar a cabo lo que pretendía. El caso es que Dart permite hacer llamadas a funciones y objetos Javascript sin ningún problema, y de una forma bastante cómoda, convirtiendo colecciones de una manera sencilla. También se le pueden mandar funciones Dart que sirvan de "callback" y se las llame desde JS. Sin embargo, la integración tiene una limitación importante, y es que no se puede llamar a objetos Dart desde código Javascript. Esto invalida por completo la posibilidad de usar un framework como es MelonJS, ya que en él todas las entidades del juego se definen como objetos a los que invoca el núcleo Javascript de la librería.

Un día entero perdido con la tontería. Y en realidad es culpa mía, porque lo ponía muy claro en la documentación. Odio los Lunes.

Problemas APIs HTML5

Como había oído que el sonido daba problemas, decidí usar la librería Howler para que ella se encargue de elegir el fichero de audio adecuado según el navegador, poniendo versiones de los sonidos en mp3, ogg y wav. En este caso al no tratarse de un framework no tuve ningún problema para encapsularla en clases Dart. Pensaba que con esto ya conseguiría que los sonidos y músicas sonaran en todos los navegadores modernos pero... craso error. Ni así. El tema del audio en los navegadores es un berenjenal de cuidado. He ido probando en varias versiones y nunca sabes si te va a funcionar o no, a veces incluso versiones del mismo navegador con muy poca diferencia entre ellas. Con Chrome por ejemplo, en Dartium no funciona la música pero sí los sonidos, y lo mismo en otras versiones de Chrome que he probado. Sin embargo, en mi Chrome y la mayor parte de versiones que he probado sí funciona también la música. En Firefox más de lo mismo, aunque aquí a veces me ha ocurrido lo contrario, que funcionaba la música pero no los sonidos.

Rendimiento
La verdad es que hasta ahora no he cuidado nada el rendimiento del juego, ni siquiera dentro de las limitaciones que pudiera tener usando Dart, pero aun así los resultados son curiosos. En Chrome en general el juego parece funcionar bastante bien, al menos en los ordenadores en los que he probado (imagino que en ordenadores antiguos le costará más). Curiosamente, parece que funciona igual de rápido en Chrome, es decir, ejecutando el código compilado a Javascript, que en Dartium, ejecutando el código de forma nativa. En Firefox, al menos en Linux, sufre mucho más, notándose mucha mucha diferencia según el tamaño del dibujo que se intenta averiguar. En Windows me pareció que funcionaba un poco mejor, aunque pudo ser por la máquina.

En el Chrome de mi tablet Android el juego funciona, justita de rendimiento, pero funciona. Parece sufrir bastante en cuanto tiene que usar cualquier sonido, lo cual me hace sospechar que los sonidos pueden ser causantes en buena parte de los problemas de rendimiento. Al final se acabó quedando colgado. En cualquier caso no me parece muy preocupante por el momento, porque como ya he dicho no he mirado todavía nada del rendimiento, y para la versión móvil probaré con el ya mencionado CocoonJS, que espero que no tenga problemas con el sonido (y si los tiene ya les vale).

Imagino que Dart debe estar ralentizando en general todo el código, y de hecho puede que la lentitud en Firefox sea por eso, aunque tampoco me extrañaría nada que fuera sencillamente un tema de rendimiento de las librerías HTML5, que no las veo demasiado optimizadas. Aunque la conclusión principal que saqué de charlas del GameMe5 es que el rendimiento de Javascript es muy muy muy sensible, y un pequeñísimo cambio puede causar de repente un gran aumento en la velocidad. En cualquier caso, en principio para este juego me vale.

Programando en Dart
Esperaba que Dart me diera algún problema: que las herramientas no funcionaran bien, que me encontrara con algún bug molesto en alguna librería, que no encontrara documentación sobre las librerías... Sin embargo, no ha sido así, todo ha funcionado como la seda.

El IDE funciona muy bien. A pesar de tener tipado opcional, hace una buena inferencia de tipos y permite autocompletar, buscar referencias, refactorizar o navegar por las clases incluso en variables sin tipo explícito declarado. Encontré algunos errores en esto, en cuanto a variables de las que de repente es incapaz de inferir el tipo aunque un rato antes sí lo hacía, pero lo considero errores menores e imagino que se arreglarán. También detecta errores de llamada a métodos o propiedades inexistentes, aunque al ser un lenguaje dinámico los marca como warnings en lugar de errores. Hubiera preferido lo segundo, pero me vale, e imagino que en el futuro permitirán esta opción.

Dartium, el navegador que incluye la máquina virtual Dart para ejecutar de forma nativa, funciona también muy bien, y el debugger tampoco me dio ningún problema. Incluso, me encontré alguna sorpresa agradable como que cuando el debugger te muestra los atributos de un objeto, te incluye también los valores de sus getters, es decir, de las propiedades que tenga que se calculan a partir de una función en lugar de devolver directamente el valor de una variable. Esto es comodísimo.

Me encontré muy cómodo también con el lenguaje. Me fastidia el que las reglas de estilo recomienden tabulaciones de dos espacios, que creo que hacen el código menos legible, y al venir yo de lenguajes de tipado estático me costó un rato hacerme a la idea de que no tenía por qué declarar tipos en variables locales (en propiedades de clases y parámetros de métodos yo que tú sí lo haría siempre). Todo lo demás me encantó desde el principio. No eché nada de menos al plasmar un diseño orientado a objetos, tiene sus clases, objetos, clases abstractas, e incluso modificadores de atributos interesantes para el control del código como const y final. Pero sobre todo el lenguaje tiene un montón de "azúcar sintáctico", con comodidades muy importantes como los getters/setters implícitos, las funciones lambda, los parámetros opcionales y/o nombrados en los métodos, los constructores con inicialización directa de propiedades con argumentos, el operador en cascada y el manejo de colecciones.

Las librerías estándar también son muy completas y están muy bien documentadas, existen clases para cualquier cosa básica que se te puede ocurrir a hacer y, también muy importante, se encuentra cualquier cosa muy rápido buscando en http://api.dartlang.org/. Si se quiere hacer algo más especializado (aunque a mi no me ocurrió), también existe un repositorio de librerías en el que es fácil buscar: http://pub.dartlang.org/ y gracias al gestor de paquetes incluido en Dart, pub, usar cualquiera de esas librerías es muy sencillo.

Lo más importante que puedo decir es que olvidé por completo la sensación de que estaba programando para el navegador. Creo que la separación entre programación "front" y "back", aunque tenga cierto sentido, es un poco artificial. Se ha hecho muy necesaria de unos años a esta parte en programación web porque programar para la parte cliente era un infierno, en el que contaba más conocer los truquillos y las compatibilidades en los navegadores que la programación real. Pero eso está cambiando mucho: con jQuery y demás librerías JS nos podemos olvidar de las incompatibilidades en el acceso al DOM, con Bootstrap (como ya comenté en otro artículo) y otras librerías de LESS y SASS nos podemos olvidar en buena parte de los dolores de cabeza con el CSS. Con Dart podemos dar un paso más y olvidarnos de la problemática de Javascript y sus librerías, comenzando a programar exactamente igual a como se hace en la parte back, al menos en mi caso, con un diseño orientado a objetos, con encapsulación, con librerías potentes, con tipado, con las facilidades de un buen IDE...

El resultado

Se puede acceder al juego online en esta dirección: https://googledrive.com/host/0B-qqsnsC2gHuS210TnQ4cENGSkk/index.html

Es completamente jugable, aunque sólo tiene 4 niveles y a veces le pasan cosas raras. Esta es la versión que presenté en la demo del Viernes de la PiWeek. Tampoco hay instrucciones, así que lo cuento aquí: botón izquierdo del ratón = negro, botón derecho = blanco (se ve como una X con sombras).

Mi intención es mejorarlo y convertirlo en un "juego de verdad". Se pueden hacer un montón de cosas, como:

• Añadirle muchas más fases: una de las grandes ventajas (y también alicientes) de este juego es que añadir más fases es tan fácil como añadir un pequeño dibujo pixelado... y si empiezas a tirar del hilo de los juegos retro ¡hay un montón!. Tres de los cuatro dibujos de la demo están hechos así, uno de ellos incluso con un gráfico propio de un mono que era el sello de mi "marca" de juegos de Spectrum, ¡sniffffff!. ¿Reconoces los otros dos?.
• Mejorar el código, sobre todo el loop principal del juego y la carga de recursos, ya que me basé en el código del taller de Gameme5 y no me gusta mucho cómo les quedó esta parte. Tengo localizada ya una librería para el loop y otra para la carga de recursos, ambas con buena pinta.
• Versión para móviles (probando CocoonJS)
• Modo "duelo" multijugador, que me permitiría también probar a hacer un mini servidor en Dart (y reutilizar clases de la parte cliente), y probar los WebSockets.
• Conectarlo con Facebook y/o Google Play Games.

En definitiva: Dart me ha funcionado muy bien, HTML5 un poco más regular, y sobre todo me ha encantado la experiencia y me lo he pasado muy bien. Y lo mismo... hasta acaba saliendo como resultado un juego de verdad. Permanece atento a la pantalla.