Mostrando entradas con la etiqueta videojuegos. Mostrar todas las entradas
Mostrando entradas con la etiqueta videojuegos. Mostrar todas las entradas

Jugar mientras conduces ES POSIBLE

Tanto cacharrito, tanto Internet de las cosas, tanto móvil, tablet, reloj, gafas, pulsera, ¡tanta leche!... y oye... ¡¡¡que KITT, el coche fantástico, sigue sin existir!!!.

El glamour y chulería de David Hasselhoff van aparte, practica todos los días frente al espejo y lo conseguirás. ¡Tú puedes!

"Smart cars"

Lo cierto es que se está trabajando en ello, pero claro, no se tarda lo mismo en hacer un coche que una pulsera. El camino se está marcando: BMW y Chevrolet apuestan por los iPhone y su Siri Eyes Free, y parece que ya ha salido algún modelo y se esperan más durante este mismo año. Otros como Ford apuestan por un sistema Sync de Microsoft, sobre el cual tengo unas ganas enormes por ver cómo reproducirán de forma sonora los pantallazos azules (apuesto a que sonará como los pitidos de carga de juegos del ZX Spectrum).

Audi parece hoy por hoy la más atrevida, y apuesta por su propia pantalla Virtual Cockpit integrada en lugar del clásico cuadro de mandos, y apuesta por la estandarización de Android y se alía con Google y otros fabricantes como General Motors, Honda y Hyundai para crear la Open Automotive Alliance.

En fin, aparentemente la baraja está lista y sólo queda echar las cartas. La referencia por ahora es el CES2014, que es donde se han presentado todas estas novedades de los coches, y según eso aparentemente este mismo año se empezarán a ver cosillas en la calle. De hecho, si comparamos las fotos que se están mostrando ahora de los cuadros de mandos de Audi con el de KITT la verdad es que por ahí ya vamos ganando.

Audi Virtual Cockpit
Más Audi, ¡leche!
KITT, vintage a tope pero... ¡más mono!

¿Y qué harán estos smart cars, o como vayan a llamarlos?. Navegador GPS, claro. ¿Y aparte?... ayudas para aparcar, que el coche te lea los wasap y correos, ayudas a la conducción... ¡BOBADAS!. Vale, seguro que el coche conduce mejor que mucha gente pero ¿de verdad te vas a fiar hoy por hoy de lo que conduzca?.

A mi todo eso me da igual. Yo lo único que quiero es que ya que tiene tanto cacharro y tanta gaita, cuando tenga un viaje en el que vaya yo solo conduciendo no tenga que estar aburrido oyendo música o cualquier chorrada que pongan en la radio. Lo que yo quiero es que... ¡PUEDA JUGAR!.

Sin matarme al hacerlo, claro.


¿Cómo puedo jugar sin usar las manos ni apartar la vista?

Esta es la pregunta clave: ¿es posible?. Previsiblemente, al menos cuando la cosa esté lo bastante avanzada, el interfaz con el smart car tiene que ser fundamentalmente a través de la voz. Cada vez que quieras que el coche haga algo, le hablas. Para que reconozca que quieres hablar con él, supongo que al principio seguramente tengas que pulsar un botón o una palanca del volante, pero lo normal es que llegue un momento en que el coche esté continuamente activo esperando a que le digas algo, y que reaccione ante una palabra clave: su nombre. Incluso, se podría poner en "modo conductor solitario" y que reaccionase ante cualquier cosa que le dijeras sin tener que decir su nombre.

Se ha trabajado mucho en reconocimiento de voz últimamente. Antes en inglés todavía, pero en español no reconocía ni papa. Ahora con los avances del Siri de Apple y el Google Now, más otros "outsiders" como Sherpa (que además es español), el reconocimiento de voz está mejorando cada vez más. Ya se puede hablar con el móvil y mientras lo hagas con cierta calma, funciona bastante bien. Cualquiera podéis hacer la prueba con vuestro smartphone, si no lo habéis probado aún. Creo que todavía le falta un puntito para que sea más cómodo, para poder hablar con menos cuidado y que te siga entendiendo, pero no me cabe duda de que se conseguirá.

El coche, por supuesto, también responderá con la voz. La síntesis de voz también funciona muy bien actualmente. Cualquiera que hayáis usado un GPS en vuestro móvil lo habréis visto. Existen otros motores de síntesis de voz más avanzados, que a menudo son de pago. El reto en este caso es conseguir que la voz tenga alma. Que sea capaz de entonar un poco, no sólo leer. ¡Diablos, al menos como lo hacía KITT, que tampoco era el alma de la fiesta!

Entonces, de lo que se trataría es de encontrar un tipo de juego que se pueda jugar sólo con la voz, hablando con el coche. Y que no sea el "veo veo", vaya.

El caso es que existe un tipo de juegos que encaja perfectamente con esta forma de comunicación: las aventuras conversacionales.


Aventuras conversacionales

Sin gráficos: Fotopía

Las aventuras conversacionales, o interactive fiction (IF) como se las conoce en inglés, son un tipo de juego antiiiiiiiiiiiiguo. La primera se considera que es Adventure, data del año 1975 y se programó en Fortran en un PDP-10. O sea, tela. Sin embargo, vamos a ver cómo su simplicidad y su falta (o no necesidad) de gráficos juegan muy en su favor en este caso.

Distribución típica, con gráficos arriba: Alien

En una aventura conversacional, se te cuenta una historia y se te pone en situación y describe tu localización actual mediante texto. Entonces tú, el jugador, escribes también por texto y en lenguaje "natural" lo que quieres hacer. El juego devuelve el resultado de tu acción otra vez como texto, y así sucesivamente, de forma que se crea una conversación entre el juego y tú. La historia va evolucionando con lo que vas haciendo, y se te van presentando retos y puzzles a resolver.

de computeremuzone.com
Puede que te suenen porque en España tuvieron su época dorada en los años 80-90, cuando Aventuras AD lanzó para los ordenadores de 8 bits juegos como La aventura original, Don Quijote, El Jabato o La Diosa de Cozumel. Incluso, por entonces llegaron a España varios juegos en inglés, especialmente El Hobbit, y que obligaron a muchos jóvenes de la época a tirar de diccionario. Aunque ya por entonces la mayor parte de los juegos tenían gráficos descriptivos de las localidades, lo cierto es que dichos gráficos eran normalmente superfluos y no afectaban al desarrollo del juego, y su objetivo fundamentalmente es hacer los juegos más atractivos a la vista (cosa que nos importa poco mientras conducimos).


Este tipo de juegos, evidentemente, encaja perfectamente con un interfaz de voz. Tú dices lo que quieres hacer, el coche responde. Curva cerrada a la derecha, te callas y te concentras. Vuelves al juego, dices lo siguiente... te puedes tirar un montón de tiempo así. Y creo que a la vez, aparentemente no es tan inmersivo como para que pierdas la concentración en la conducción.

Y además... ¡son un tipo de juegos muy divertidos! (incluso si no los comparamos sólo con el veo-veo).

Esta sería una hipotética transcripción de una conversación entre KITT (obviamente llamaríamos así a nuestro coche) y tú, que dé paso a una sesión de jugar una aventura:


KITT: Buenos días, Andrés

Andrés (reemplázalo con tu nombre para disfrutarlo más): Hola, KITT

K: ¿Dónde vamos?

A: Vamos a casa

K: ¿A casa, a la calle Ríos Rosas?

A: Sí, eso es

(KITT programa el GPS y tú mientras arrancas y te pones en camino)

A: KITT, vamos a jugar a Olvido mortal

K: Cargando Olvido mortal. Continuamos la partida que dejaste ayer. ¿Correcto?

A: Sí

KITT: Oficinas
Estás en una especie de oficinas.
No ves ningún cartel que te indique qué lugar es este. La cola se extiende por la alargada localidad, enorme. Por detrás, una pared te impide ver dónde acaba. La fila de gente continúa por una puerta abierta en la pared.
En el otro sentido, las cabezas te impiden ver qué hay al principio de la cola.

La mujer de delante en la cola parece ser la única persona que te presta algo de atención.


(un chalao se te cruza en ese momento y te centras en lo tuyo)

A: Perdona, KITT, ¿puedes repetir?

K: Oficinas.......... (y repite toda la descripción, ¡más majo!)

A: Resumen

K: Despertaste en la cola sin recordar quién eras ni dónde estabas.

A: Inventario

K: Llevas: una cartera (que está cerrada)

A: Abre la cartera

K: Abres la cartera, descubriendo un carnet de identidad y una foto.

A: Mira el carnet

K: Es un carnet de identidad normal y corriente. La foto del carnet está un poco difuminada, pero se ve lo suficiente.

"¿Es posible que ese sea yo?. Desde luego, la cara me resulta familiar, pero no soy siquiera capaz de asegurar tajantemente que sea la mía."


(...)
(y así pasa el tiempo y cuando te quieres dar tiempo estás ya en casa... ¡y no quieres dejar de jugar!)



¿Qué tal, te convence?. ¡¡¡A mi sí!!!

Otra buena noticia es que muchos de estos juegos son multi-plataforma y se ejecutan sobre una máquina virtual. O dicho de otra forma: es muy muy fácil adaptar un intérprete de estos juegos para que se ejecute en un coche y se juegue con la voz. Y automáticamente, en cuanto tengas hecho el intérprete, tienes disponibles cientos, miles de juegos, listos para jugar.

En español, el mejor sitio donde encontrar juegos es la web del CAAD, el sitio donde se reúnen todos los "chalaos" de este tipo de juegos y aúnan esfuerzos alrededor de la aventura. Una de las grandes ventajas que tienen estos juegos, además, es que casi cualquiera puede programar uno. No hace falta ser programador, ni tampoco saber dibujar ni componer música. Esto ha hecho que se cree una comunidad alrededor de ellos y que se sigan programando juegos. En inglés, por otra parte, la comunidad es aún más activa y para descargar juegos tenemos el Interactive Fiction Archive.

Si queréis probar con alguno de estos juegos, ¡qué demonios!. ¡Prueba alguno de los que he hecho yo! Sí, así a lo tonto y mientras hablaba de "esos chalaos" en tercera persona, os metía de tapadillo mis juegos (hechos hace ya un buen montón de años, en el 2001, ahí es ná): Olvido mortal, que ya habéis probado un poco con KITT pero podéis jugar online aquí, y Akbarr.

Forma original en forma de libro: Akbarr


Conclusión

Esto no es más que elucubrar pero, ¿por qué no?. Está todo ahí: los coches ya produciéndose integrados con tecnologías móviles como Android e iPhone, los motores de reconocimiento y síntesis de voz a un puntito de ser cómodos y molones, justo ese puntito de más que daría el interés por el mercado de los coches... y las aventuras conversacionales ahí, listas para que las juguemos charlando con nuestro coche mientras hacemos un viaje.

¿Y vosotros, qué pensáis de todo esto?...

¿Y tú, KITT?. ¿Te apetece que juguemos?.


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ónhttps://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.