Es la primera vez que el cierre de un servicio gratuito me afecta. No sé si es una victoria en mi estrategia de ser independiente (o libre si lo prefieres: pago el dominio usebox.net, tengo mi propio servidor de correo, web, copias de seguridad, etc; todo con software libre), o que no soy un gran consumidor de servicios ;).

El caso es que el cierre del lector de feeds de Google como parte de su última limpieza de primavera (desde 2011 ya han cerrado 70 proyectos :o) me ha fastidiado un poco. Somos animales de costumbres y desde que dejara de usar Liferea hace unos años, Google Reader se había convertido en uno de mis servicios indispensables (uno de los pocos que uso hasta en el móvil).

¿Por qué ha hecho esto Google? Su breve explicación (ha descendido su uso y su nueva estrategia de empresa es concentrar energías en un grupo selecto de productos) suena a broma cuando Google ha sido -y es- una empresa que diversifica constantemente; desde servicios en Internet como el buscador o correo hasta gafas inteligentes o coches que se conducen solos.

Hay muchas lecturas posibles y se ha escrito mucho en los últimos días acerca del tema, pero lo más evidente para mi es que Google+ es una prioridad para Google, y sospecho que van a intentar dirigir a los usuarios de Reader hacia su plataforma social donde Google controla los contenidos en lugar de proporcionar una plataforma para consumirlos.

En cualquier caso se veía venir un cambio. El lector de feeds estaba en una posición muy incómoda, sin novedades destacables en año y medio, siendo el último cambio el rediseño para ajustarse a la nueva imagen de producto de Google, junto a la pérdida de funcionalidades sociales por la integración con Google+. Imagino que muchas veces se ha dicho que las plataformas sociales como Facebook y Twitter han acabado con la popularidad de los blogs; en este caso es bastante literal (que tiemble Blogger, ¿podría ser el siguiente? :D).

Hay varias alternativas a Google Reader y mucha gente está frotándose las manos porque se abren las puertas a un negocio que Google se encargó de cerrar en el 2005 cuando su lector de feeds aniquiló sin piedad a la escasa competencia con un producto técnicamente superior y además completamente gratis. En mi caso por ahora he vuelto con Liferea, aunque he perdido la sincronización con distintos dispositivos; un problema que ya buscaremos solucionar, si es posible sin depender de un servicio de terceros (estaría dispuesto incluso a incluirlo en mi infraestructura).

Creo que el cierre de Reader va a tener cosas positivas y efectos interesantes. Mucha gente se ha dado cuenta de cómo dependen de recursos que no controlan, y la caída de Reader va a suponer una especie de reboot, como un gran desastre en el que muchas suscripciones se van a perder para siempre. Tenemos la oportunidad de empezar de nuevo, aprendiendo de nuestros errores.

»Presentación sobre PyWeek · Al final no di la charla en el Hack 'n Talk del pasado sábado, pero si preparé la presentación: What is PyWeek?. No conocía DZSlides y ha resultado perfecto para montar las slides en un rato (el viaje en tren de Guildford a Londres es de menos de 40 minutos).

»pyflakes · Es algo peor que pylint porque solo busca errores sintácticos y no hace recomendaciones de estilo, pero pyflakes es lo suficientemente rápido para que no hayan esas pausas incómodas al guardar el fichero cuando usamos syntastic con vim. Muy recomendable.

»Demo de raycasting · Nada, me he aburrido de la idea de usar Javascript: demasiado trabajo con poco beneficio; o que el problema ya es lo bastante difícil como para añadir la complejidad de usar ciertas herramientas. He publicado una demo del invento, y además el código en github.

»Cómo funcionan los gráficos del Dungeon Master · Igual no me quedó clara la explicación en mi anotación sobre raycasting y canvas, así que recomiendo esta entrada en un foro sobre pixelart que explica cómo se construye una escena en juegos como Dungeon Master (y aquí hay código fuente en C con SDL). Como decía, no es tecnicamente complicado, pero dibujar buenos muros es ya otra historia.

Cuando estaba investigando (o buscando inspiración) para mi experimento con el canvas de HTML5, me encontré con un blog que me gusta bastante: CRPG Revisited, donde su autor escribe artículos sobre juegos de rol para ordenador clásicos (como él dice, de antes del 2000).

Buenas horas le eché a este :)

Sé que hay más bitácoras de este mismo estilo, puede que mejores, pero empecé ojeando sus anotaciones sobre Wizardry VII y no pude parar, más o menos como me pasó con un informe publicado en el número 27 de la revista Micromanía (Agosto de 1990; sí, está en archive.org :o).

El informe se titulaba Más sobre RPG y, aunque yo no había leído el artículo que supestamente ampliaba (me compraban Micromanía muy esporádicamente, que yo tenía 13 años por aquel entonces:D), me quedé totalmente enganchado. Creo que es el texto que he leído más veces en mi vida, estudiando los pantallazos pixel a pixel; ¡eso de los RPG tenía tan buena pinta!

De hecho aquellos informes puntuales se convirtieron en una sección fija de la revista con el nombre Maniacos del calabozo, a cargo de Ferhergón (Fernando Herrera Gonzalez, creo recordar). Al final compraba la revista solo por esa sección :).

Desde entonces el género ha cambiado, se ha hecho mainstream como todo; pero aquellos años de popularidad nos dejaron muchos juegos memorables (buenos y malos). En mi época jugué a algunos de ellos, como Bloodwych, Legend, Sentinel Worlds, Drakkhen, Shadow Sorcerer, BattleTech: The Crescent Hawk's Inception o Lands of Lore.

Algunos de esos juegos han envejecido bien, al menos desde mi punto de vista de jugador ocasional, y otros no tanto (recuerdo que probé The Bard's Tale III hace un par de años y era injugable; vaya decepción después de todos los buenos comentarios de Ferhergón :P). Pero todos aportan más o menos una experiencia que recuerda a lo que es una partida de rol de tablero, algo que quizás no es tan importante en los nuevos títulos (que no estoy seguro, porque es cierto que no juego).

Por aquel entonces ya intenté programar mi propio juego de rol (en gwbasic y con más ilusión que técnica, pero en perspectiva isométrica :D), que creo que ahora es el MMORPG que todos los programadores principiantes quieren para su primer juego.

Me ha gustado mucho revisitar aquellos juegos (¡y releer el informe de Micromanía una vez más!), aunque sea vía los artículos de CRPG Revisited. Me ha vuelto a picar el gusanillo, como en los viejos tiempos ;).

No hago más que leer acerca de proyectos interesantes que nos prometen tiempos excitantes para la web, con la especificación de HTML5 como candidate recommendation desde finales del año pasado y diferentes partes implementadas a buen nivel por varios navegadores; además de Javascript cada vez pegando más fuerte.

No me gusta el lenguaje, tiene demasiados WTF, y muchos inconvenientes que hacen bastante tedioso usarlo para cosas grandes, sobretodo si disfrutas de mejor calidad de vida trabajando con otros lenguajes ;).

El caso es que he ojeado alguna vez alternativas para programar juegos con Javascript, pero nunca he llegado muy lejos con ninguna de ellas. Quizás sea por la barrera de entrada (hay que saber manejar el framework antes de empezar a hacer algo), o porque es fácil dispersarse :).

Hace un par de fines de semana me puse a investigar el elemento canvas, directamente sin ningún tipo de arnés (¡y sin red! :D), empezando con el tutorial de canvas de Mozilla. Y bueno, sin ser genial, se puede dibujar directamente mediante un interfaz que enseguida me resultó familiar.

Pues ahí estaba yo cacharreando con el canvas y se me ocurrió hacer un cutre-motor que imitara el falso 3D de juegos tipo Dungeon Master. Es bastante más sencillo de lo que parece: hay un limitado número de piezas que vamos poniendo en pantalla en el orden adecuado siguiendo el algoritmo del pintor (dibujamos las piezas de más lejos a más cerca respecto a la posición del espectador).

Ya lo hice una vez hace unos cuantos años, pero me aburrí pronto porque las piezas para construir el escenario en 3D son complicadas de dibujar (como siempre, no soy un artista), así que se me ocurrió: ¿por qué no usar raycasting? Se trata de una técnica para dibujar un pseudo-3D que se usaba en juegos hace años, destacando Wolfenstein 3D y poco más tarde Doom (hay muchos más, pero con estos dos queda claro a qué me refiero).

La idea es que crear una textura que pegar en los muros es relativamente fácil (mucho más que dibujar en perspectiva las piezas del escenario como en Dungeon Master), y además la transición entre posiciones del jugador puede ser suave en lugar de los saltos habituales de los juegos tipo DM (hablamos de finales de los años 80 :P). La cuestión era si canvas me daría suficiente rendimiento para implementar un raycasting sencillo. La respuesta es: casi.

Prueba usando un degradado para suelo y techo, con iluminación en profundidad

Tras leer un par de tutoriales sobre raycasting (Ray-Casting Tutorial For Game Development And Other Purposes es el más clásico, usando ángulos; y Lode's Computer Graphics Tutorial: Raycasting que emplea la técnica del Digital Differential Analysis, más sencillo de implementar en mi opinión), me puse a hacer pruebas y los muros se pueden dibujar a una velocidad más que aceptable gracias a que se dibujan linea a linea horizontalmente, y se puede optimizar el proceso copiando trozos de la textura en bloques de 1px de ancho por el alto del segmento de muro que toca dibujar, dejando que el navegador escale la textura por nosotros.

Más o menos la misma idea se puede aplicar para los sprites (o lo que es lo mismo: cualquier objeto que no es un muro), aunque el efecto resultón que consigo para cambiar la iluminación de los muros en base a la distancia no se puede implementar igual porque los objetos tienen una parte transparente que estropea el tintado (se ve una mancha oscura alrededor del objeto).

La parte del casi es porque la técnica para dibujar el techo y el suelo es diferente a la empleada con los muros, y resulta demasiado costosa porque no he encontrado atajos para hacerlo rápidamente con el canvas (hay que proyectar punto a punto, y es muy lento).

Muros y suelos con textura, pero a menos de un cuadro por segundo :(

Al final he dado con unos degradados que no quedan del todo mal, y creo que tengo el motor con la suficiente funcionalidad como para hacer un juego; aunque me faltan cosas, como hacer que el jugador interaccione con los objetos (click en pantalla, proyectar las coordenadas y trazar un rayo hasta que impacte -o no- con un objeto; ¡fascinante! :D) o implementar puertas. A priori yo diría que se puede hacer, porque en mis pruebas con Chromium y Firefox consigo alrededor de 30 FPS, que es más que suficiente.

Seguiré comentando el experimento, porque parece que la cosa se me está alargando un poco más allá de proyecto de fin de semana, y quién sabe si puede salir algo interesante de todo esto :P.

Actualización: he publicado una demo de raycasting en canvas HTML5.

»syntastic · Hace unos meses expliqué mis dotfiles y la verdad es que no uso muchos plugins para vim (incluso alguno he quitado desde entonces). Hoy he probado syntastic (con pylint), y creo que puede convertirse en uno de mis indispensables, aunque es pronto para saberlo :P. Sirva esta nota como respuesta a un comentario de wavelopez sobre Python y pep8.

Actualización: ah, le he encontrado una pega: con ficheros grandes (bastante) en proyectos complejos (mucho), pylint puede ser algo lento, lo que supone una pausa de incluso segundos cuando guardamos el fichero. Creo que este problema puede ser fatal :(.

»PyWeek 16 · Ya hay fechas para la PyWeek 16, que será el próximo Abril. He participado dos veces, la primera abandoné y la segunda conseguí entregar un juego (incompleto, pero se puede jugar un rato). Debería empezar con los entrenamientos a mucho tardar en Marzo, a ver si conseguimos otra entrega :D.

No es que sea demasiado complicado, pero es la segunda vez que monto gitweb para tener un frontal web para mis repositorios git, que no todo va a ser github, y siempre me atasco en algo. Sirva esta anotación para no volver a perder el tiempo por despistes ;).

Como mi servidor es una Debian Squeeze, la primera parte es sencilla:

# apt-get install gitweb libfcgi-perl

gitweb tiene soporte para fastcgi mediante CGI::Fast, solo que la documentación no es nada clara. Si instalamos esa dependencia no necesitaremos nada especial para usarlo con nginx (que no tiene soporte para el modo de trabajo por defecto de gitweb: CGI clásico); me enteré leyendo su código cuando ya había casi acabado mi wsgi2cgi :(.

Una vez que tenemos gitweb instalado hay que ajustar la configuración (por defecto en /etc/gitweb.conf):

# dónde se encuentran los repositorios
$projectroot = "/home/code/git";
# para el 'title' de la web
$site_name = "Mis repositorios";

El resto se puede dejar por defecto.

Lo siguiente es la configuración de nginx, añadiendo un nuevo sitio en /etc/nginx/sites-available/ y creando el enlace simbólico correspondiente en /etc/nginx/sites-enabled/.

Este tema es un poco personal, pero lo que he montado es algo así:

server {
    listen   80;

    server_name  whatever.usebox.net;
    access_log   /var/log/nginx/whatever.usebox.net.access.log;

    root         /usr/share/gitweb;

    location / {
        if (!-f $request_filename) {
            fastcgi_pass   unix://tmp/gitweb.sock;
        }
        fastcgi_index  index.cgi;
        fastcgi_param  SCRIPT_FILENAME  /usr/share/gitweb/index.cgi;
        include        fastcgi_params;
    }
}

Yo me he creado un subdominio (que no se llama whatever, claro :P), y lo único especial es:

• La raíz de la web estará donde instala gitweb (ahí hay algunos ficheros estáticos a parte del CGI).
• Si se intenta acceder a un fichero que existe (por ejemplo git-logo.png), se servirá; sino se pasará la petición a gitweb vía fastcgi. He usado un socket unix para fastcgi, pero se puede trabajar con TCP igualmente.
• El índice de la web será el script de gitweb, y pasamos algunos parámetros de lo más normales (incluyendo todos los parámetros estándar que vienen en /etc/nginx/fastcgi_params).

Como digo esto va a gustos. Y lo mismo para el siguiente paso: arrancar gitweb.

Ahora mismo uso supervisord para este tipo de cosas. Creamos un fichero de configuración en /etc/supervisor/conf.d/ tal que:

[program:gitweb]
command=/usr/lib/cgi-bin/gitweb.cgi -f
environment=FCGI_SOCKET_PATH="/tmp/gitweb.sock",FCGI_LISTEN_QUEUE="20"
directory=/usr/share/gitweb/
user=www-data
autostart=true
autorestart=true
redirect_stderr=true

Podría haber creado un usuario especial para ejecutar el proceso, pero como el servicio en mi caso es privado y no va a estar expuesto al público, he usado www-data. Hay que tener cuidado al pasar las variables de entorno, poniendo entre comillas los valores si tienen caracteres alfanuméricos (se pueden poner siempre y evitamos despistes).

Si tenemos supervisor ya ejecutando, podemos recargar la configuración y lanzar gitweb con:

$ supervisorcrl reread
$ supervisorcrl update
$ supervisorcrl start gitweb

Si algo no funciona como esperamos podemos mirar los logs de supervisor (aunque gitweb es muy poco explicativo cuando hay problemas :S).

Reiniciamos nginx y con esto ya podemos visitar nuestro subdominio y acceder a la vista web para nuestros repositorios (si los permisos son correctos, pero eso ya lo dejo en manos del lector interesado :P).

Para terminar comentar que hay un tema para gitweb muy resultón, que mejora bastante el aspecto por defecto; aunque la funcionalidad es la misma (y ojo que necesitamos un gitweb a la última, y la versión de Squeeze es algo vieja).