Ciro Durán Un archivo vivo

Mi música en 2023 disponible en la página

Como en años anteriores, he publicado la música que hago como parte de la hora semanal del Tuesday Tunesday que hago entre amigos. Por favor, ve a música en 2023 para escucharla.

Resumen del Caracas Game Jam 2024

Como ha sido usual en los últimos años, he escrito el resumen del Caracas Game Jam 2024. 46 participantes en el sitio, y 15 online, han hecho 17 juegos, cuyos videos de gameplay están compilados en un solo video. Mi agradecimiento a los organizadores, que hicieron un gran trabajo este año, marcando la vuelta a una sede física desde 2020. Por favor, lean el resumen y vean el video.

20 años de Tómate un descanso

El 25 de octubre de 2003 publiqué el demo de Tómate un descanso (que con el paso del tiempo dejó de ser demo y pasó a ser el juego) en el foro de Adventure Game Studio. Los enlaces del post original lamentablemente ya no existen, pero el juego se puede descargar desde esta misma página. Una copia del post en los foros de AGS está también aquí (porque uno nunca sabe).

Tómate un descanso es un juego de aventuras tipo point and click fuertemente inspirado en los juegos de Lucasarts de la época, como Day of the Tentacle. Fue hecho con Adventure Game Studio, un software que hasta la fecha sigue siendo utilizado para hacer juegos en este estilo. Tómate un descanso fue el primer juego que publiqué en internet, aunque no el primero que hice. Eso se lo lleva algunos juegos que hice con GameMaker, de Recreational Sofware Design y alguna versión de Paint Shop Pro y se perdieron como lágrimas en la lluvia. Lamentablemente, las fuentes de Tómate un Descanso se perdieron con un disco duro y ya no existen, sólo el ejecutable que sobrevive hasta hoy.

En el juego, Albert Krakowitz es un oficinista que quiere escaparse de su trabajo para irse de viaje a la ficticia y caribeña Isla de Bastidores. El demo fue pensado como una suerte de cold intro para el juego, con la mayoría de la historia desarrollando las desventuras de Al y el compañero de viaje, con él posiblemente regresando a su casa como un hombre renovado.

El juego fue publicado con el convencimiento de que era una demo para un juego mucho más largo y complejo, pero eventualmente pasé a tener otros intereses y el demo se convirtió en el juego completo. Yo hice las ilustraciones y animaciones del juego, y parte de la música. En 2003 estaba en plenos estudios universitarios, pero veníamos de una época dificil como lo fue el paro petrolero de 2002. Durante el paro, donde tampoco hubo clases, fue el momento donde desarrollé la mayor parte de este juego. Las ilustraciones fueron hechas a mano, digitalizadas y pasadas a pixel art. La música, salvo la pieza que sale en la intro, la hice yo, no recuerdo con qué secuenciador MIDI.

Tómate un descanso tuvo su walkthrough escrito por Francesc Planas, el enlace a la página original ya no existe, pero puede ser accedido a través del Wayback Machine (Anexo también una copia de esa entrada del Wayback porque uno nunca sabe). Esto lo sé por una entrada que escribí en El Chigüire Literario. El juego tuvo reseñas en blogs personales que hoy en día tampoco existen (un saludo a Rolando Hernandez y su blog Moderno Prometeo).

El conocimiento que obtuve con el juego luego lo aproveché para crear un tutorial de AGS. Como mucha documentación, la herramienta que cubre evoluciona y cambia, y este tutorial quedó obsoleto eventualmente.

Tómate un descanso nunca ganó premios, y desconozco el impacto singular que haya tenido sobre otras personas. El hecho de que este juego pueda correr en una PC 20 años después de haber sido publicado es un testamento de la compatibilidad de Windows que ninguna otra plataforma, ni siquiera Adobe Flash, ha podido igualar. Sin embargo, sé que este juego fue una parte importante en mi desarrollo personal y profesional. Este juego, y todos los que vinieron a continuación, y todo lo que escribí en El Chigüire Literario, se sumó silenciosamente a mi carrera y a mi vida. Me encanta que este juego pueda ser aún jugado, y mostrar un poco de lo que pensaba hace 20 años. Me da gusto poder señalar este juego en particular y decir “esto lo hice yo en su momento”.

Preservar cosas en el tiempo es complejo. Me duele haber perdido las fuentes del juego. Pero al menos lo que sobrevive se puede seguir disfrutando.

Montando un pedal de efectos de guitarra con un Raspberry Pi

Conseguí este enlace a un software de pedal de efectos de guitarra, y me ganó la curiosidad y decidí reconstruirlo con el material que tengo a mano. El repositorio contiene código para correr un procesador de efectos de sonido de baja latencia (léase, efectos de sonido en tiempo real).

El código está escrito en C++, usando SDL2 para despliegue visual, RtAudio para interactuar con la salida de audio y crow para un servidor web que presenta la interfaz gráfica de los controles del pedal.

El material que utilicé: un Raspberry Pi 3 montado en una pantalla táctil de element14, un breadboard para montar los botones que se conectan al Raspberry Pi por el puerto GPIO, y un dispositivo de sonido con puerto de micrófono y de salida que se conecta por puerto USB. Es también la primera oportunidad que tuve de probar la pantalla táctil.

El proceso para comenzar a utilizar la pantalla no tuvo contratiempos: se atornilla el Raspberry Pi detrás de la pantalla, se conectan por un puerto especializado, y utiliza el mismo enchufe oficial del Raspberry Pi, que provee suficiente energía para ambos componentes. El Raspberry Pi en forma de tableta es un dispositivo bien interesante, aunque el setup actual está dado para mantenerlo conectado a un enchufe y no a una batería. Igual conecté un teclado porque la vida es muy corta para usar el teclado tactil.

Después de haber comprobado que la pantalla funciona, proseguimos a compilar e instalar GuitarEffects. El procedimiento está razonablemente bien definido en el readme del proyecto. Esto es mayormente instalar las dependencias con apt, y luego compilar a traves de configure, make y make install.

El único comentario que tengo sobre el proceso: la instalación de RtAudio funcionó prácticamente fuera de caja (sin pasar opciones extra). Sin embargo, tuve un mensaje de error cuando intentaba hacer configure: No known system type found for realtime support!. Para resolver esto tuve que instalar el paquete de desarrolladores de ALSA, sudo apt-get install libasound2-dev, y luego el proceso continuó sin más errores.

Una vez todo compilado, corrí sudo ../bin/server desde el directorio web del repositorio. En este momento el programa no pudo determinar cuál iba a ser el dispositivo de audio que iba a utilizar, y lo preguntó por el terminal. Una vez seleccionado mi dispositivo de sonido, el programa abre una ventana que muestra la onda de audio en tiempo real.

El programa sirve una página web que ofrece los controles completos del pedal. Se puede abrir dentro del propio Raspberry Pi o desde otro dispositivo en la misma red.

Lo que queda es conectar un instrumento, unas cornetas y comenzar a tocar.

Decidí usar el Raspberry Pi 3 porque el 4 que recientemente adquirí pasó a ser mi servidor Samba de archivos, reemplazando el viejo RPi 3. Creo que la potencia del 4 me hizo falta, pues noté bastante crujido y popping, seña de que el desempeño no es suficiente. Hay maneras de configurar el Pi para mejorar el desempeño del audio en tiempo real, incluyendo desactivar servicios como networking. Esto en particular para este proyecto no es una opción dado que corre un servidor web.

Los botones no me funcionaron cómo lo declara el readme del proyecto. Sin embargo, esto fue algo a lo que no le presté mucha atención dado que la interfaz web me entretuvo suficientemente. El pedal al momento ofrece una cantidad de efectos interesantes: autowah, filtros de paso alto y paso bajo, flanger, fuzz, delay, distorsión, compresor, reverberación, looper, entre otros más.

Como experimento me pareció muy interesante, y es un proyecto sólido con mucho potencial. Algunas cosas que hubiese hecho con un poco más de tiempo:

  • Hacer funcionar los botones: la documentación no deja claro qué hacen específicamente, así que tampoco vi la necesidad de hacerlos funcionar
  • Mejorar el desempeño de audio en tiempo real: el artículo que enlacé anteriormente tiene buenas sugerencias. Mi setup no incluye ventilador, así que no quise lidiar con overclocking. La interfaz web presenta la temperatura del sistema, y no varió en la hora que estuve tocando. Sería cuestión de leer y evaluar la factibilidad de cada sugerencia

Postmortem de RootPump

Video de RootPump como fue entregado en el Caracas Game Jam 2023

Un Caracas Game Jam más, otro juego hecho, otro postmortem. Estuve casi a punto de escoger PICO-8 nuevamente, pero en un arranque de iluminación decidí darle oportunidad a una herramienta que tenía tiempo queriendo usar: Godot Engine. Godot se ha popularizado en el Global Game Jam como una alternativa a los notorios Unity y Unreal Engine, y al ser un proyecto de código abierto, ha atraído a un segmento bien particular de los desarrolladores de videojuegos. RootPump (entrada en el Global Game Jam) fue el resultado de este año, y la experiencia me permitió formarme algunas opiniones acerca de Godot. El código fuente del juego está en GitHub.

Para comenzar a usar Godot basta con bajar el ejecutable de su página de descargas, la versión 3.5 estable que es la más reciente al momento. Conocía abstractamente que Godot tenía soporte para GDScript, su lenguaje de scripting parecido a Python, y C#. Estoy familiarizado bastante con C# así que me fui por la opción de Godot con soporte para este lenguaje. Con Visual Studio Code ya previamente en mi máquina, instalé las extensiones godot-tools y C# Tools for Godot para facilitar el desarrollo. Durante el evento, cloné el repositorio de código fuente de Godot y esto me permitió navegar en el código desde mi proyecto y resolver muchísimas dudas.

La documentación oficial de Godot es bastante útil. No sólo contiene referencia al código, sino que también tiene artículos para ayudar a implementar lo que tengas en mente. Sin embargo, la documentación oficial generada sólo incluye la referencia a GDScript. La interfaz en C# está documentada en el código, así que es cuestión de generarla para tener una referencia igual de buena que la de GDScript, y paulloz ha tenido la cortesía de generar esta documentación, lo cual fue clave para entender el motor y entender las diferencias con GDScript. Sería bueno que esta referencia estuviese incluída en la documentación oficial si Godot sigue manteniendo su interfaz en este lenguaje.

Concebí RootPump como un juego de ritmo en el que las raíces de una planta crecen de acuerdo a cómo el jugador lleve el ritmo de una canción. Idealmente el gameplay del juego se llevaría a cabo con un solo botón. Decidí que dibujaría los gráficos con cualquiera que fuese la interfaz de código para dibujar en 2D en Godot (al momento lo desconocía), y que utilizaría la interfaz para reproducir audio pre-grabado (también lo desconocía).

Fue entonces una sorpresa agradable conseguirme con un sistema para componer escenas que me es familiar: en Godot una escena es un archivo que contiene un árbol de nodos Node2D. De esa manera, es posible obtener algún nodo a partir de un string (e.g. “Cosa1/Cosa2” para obtener el nodo llamado Cosa2 anidado en Cosa1). Es posible conectar un nodo con un script, y así es posible escribir código para ese nodo. Y así fue mayormente mi ciclo de desarrollo: usé el editor para añadir algunos nodos básicos, poner los elementos de las pantallas, y de resto pasé la mayor parte del tiempo en VSCode escribiendo código para luego probar los cambios en el editor.

Godot tiene una buena cantidad de rutinas matemáticas (Math2f) específicas para videojuegos y no pasé tiempo reimplementando esa funcionalidad. Si ya sabes lo que quieres hacer, todo está a la mano. Godot también ofrece una implementación del patrón observable llamado Signals, en el que es posible que los objetos interesados estén informados cuando ocurre un evento. Esto forma parte de Node2D, así que es muy fácil integrarlo. Sin embargo, en la implementación de mi juego hice varias cosas que no descendían de Node2D y no me fue posible usar las señales.

El sistema de input de Godot me gusta. Godot tiene un mapa abstracto de acciones, y a cada acción se le asocia un botón (o tecla, o acción del control), y luego en código se comprueba si esa acción está presionada, o “ha sido apenas presionada” (para acciones que solo requieren comprobar la primera vez que pasa en un frame).

Godot tiene un sistema de plugins para aumentar la funcionalidad del editor. Solo tuve la oportunidad de probar un plugin, el de git para manejar el versionamiento. Es un buen plugin, provee una interfaz gráfica para git, pero nada que TortoiseGit no ofreciese ya.

La otra agradable sorpresa fue conseguirme con una interfaz de audio bastante buena. Es posible tener varios canales de audio (Audio Buses, se llama el concepto), a los cuales es posible aplicarle efectos de sonido separadamente. Godot incluye también una sección que describe cómo sincronizar el audio con el juego lo cual me cayó de perlas y me ahorró mucho tiempo. La música la hice con Ableton Live, pero realmente no le presté atención, así que me fui por lo más básico. Finalizada la música, exporté los 3 stems a MP3 por separado, y en el juego se escuchan los 3 canales simultáneamente. Me quedó la curiosidad de todas las cosas que se pueden hacer con este setup.

Finalmente aprendí cómo hacer builds de mi juego, hasta entonces sólo había probado directamente dentro del editor. Godot tiene templates para exportar, uno por cada plataforma a la que puedes hacer un build (Windows, Mac, Web, etc.). Esto es una descarga separada que se inicia dentro del mismo editor. Desde el principio había considerado hacer RootPump para Windows, pero definitivamente tenía la curiosidad de ver cómo se comportaba el juego en web. Lamentablemente, el juego se tranca como a los 3 segundos de iniciar la ronda, y creo que es por el setup del audio que hice. Creo que hace falta ser más cuidadoso para exportar a Web, y es algo que vale la pena hacer con más calma, sin la presión de un game jam. Gracias a Edmundo que probó hacer el build en Mac: funciona bien salvo que el build pide permisos para usar el micrófono, y esto está aparentemente cableado en la presente versión de Godot.

El tiempo al final se me hizo corto para implementar el mínimo que esperaba al término del evento. En efecto tengo un árbol que crece, un pulso que se mueve a cierto ritmo, y un mecanismo para comprobar si el jugador va al ritmo de la canción que suena. Los dos mecanismos no están conectados, lamentablemente. Me hubiese gustado que el jugador tuviese mayor control de la dirección del pulso, y tal vez el control hubiese necesitado una dirección para mover el pulso.

Al final, las limitaciones fueron de tiempo, y siento que la herramienta trabajó conmigo, y no en contra mío. Escogería Godot nuevamente para un próximo proyecto.