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.
En noviembre del año pasado hubo grandes cambios en el Tuiter. Desde entonces había querido dejar por escrito algunas opiniones, y aunque ya era evidente lo que iba a pasar, no dolió menos cuando cada cambio se hizo realidad. Este post es más bien un conjunto de pensamientos alrededor de lo que fue Twitter, y un poco de cuáles serán los próximos pasos para mí.
Desde 2007 Twitter para mí fue una plaza pública. Al principio mi comunidad eran los blogueros venezolanos con los que compartía mis posts en El Chigüire Literario. En esa época éramos pocos, lo que nos permitía ser mucho más francos. La intervención del gobierno venezolano en los medios significó que muchos vieron en Twitter el medio donde nos podíamos enterar de lo que estaba pasando. Twitter pasó de ser una mera curiosidad a un lugar importante en el discurso diario. En la plaza pública ya no estábamos sólo unos pocos: pasamos a ser muchos. Y con una masa crítica llegó la viralidad.
La viralidad implica que un mensaje bien puesto puede llegar lejísimos, pero también implica escribir con una mentalidad de que potencialmente cientos de miles de personas de pueden leer. No solamente leer, sino responderte de vuelta. Twitter realmente nunca tuvo herramientas efectivas para controlar una situación así. No todo el mundo tiene la preparación mental adecuada para encontrarse en una situación así. Ser virales no nos pasa en el mundo físico. Leer lo bueno y lo malo puede ser un golpe mental muy duro.
Sin embargo, creo que hice de ese espacio lo mejor que pude. Conocí gente maravillosa, gente no tan maravillosa, conseguí empleo, conecté con gente a las que considero mis amigos, aunque la distancia física no nos haga vernos las caras día a dia.
He estado mucho tiempo online, quizás demasiado. No es la primera vez que me encuentro migrando de red social. Estuve en redes sociales previo a Twitter (te extraño Pare o None). En los inicios de Twitter, cuando se caía a cada rato, compartí un poco en Plurk (al día de hoy un nombre que me sigue pareciendo horroroso). Creo que la lección más importante en todo esto es la importancia de poder preservar tus relaciones. Esto lo saben las redes sociales: por eso hay barreras tan altas cuando intentas migrar. La red social más valiosa es aquella donde está la gente que conoces y con la que charlas. Así, todas las redes sociales tratan en lo posible de mantenerte adentro. Twitter tal vez ha sido la que fue más boleta al prohibir por un rato enlazar a otras plataformas, pero todas en mayor o menor medida son jardines amurallados.
Quizás por esto es que soy insistente en seguir manteniendo una página personal. Aquí no hay mucho más que unos textos hospedados en un servidor. Desearía que no fuese necesario tanto conocimiento técnico para mantener algo así (¿tal vez te puedo tentar a escribir desde un templete como Zonelets y hospedarlo en Neocities?). Tampoco permite mucha interactividad, a lo sumo que me escribas por email (tengo la lista de correos de El Chigüire Literario en la cual escribo muy raramente cuando hay posts nuevos).
Y así llegamos a Mastodon, y al Fediverso en general. Mastodon emula muchas funcionalidades de Twitter, pero implementa un protocolo llamado ActivityPub. ActivityPub permite que cualquiera(asterisco) pueda hospedar una comunidad y compartir los posts de esa comunidad con otras comunidades. Mastodon es una comunidad que se parece a Twitter, pero hay otras comunidades que se parecen a Instagram, como las comunidades que usan Pixelfed.
La idea de la federación (y el Fediverso) es que tú te puedes unir a cualquier comunidad (o servidor, o instancia, como lo quieras llamar), y de ahí puedes seguir a otras cuentas, independientemente de la comunidad donde estén. Como el correo electrónico. En tu comunidad tienes entonces al menos 3 timelines: el timeline personal, compuesto de las cuentas a las que sigues, el timeline local, con una selección automatizada de las cuentas de tu comunidad, y el timeline federado, que es una selección del agregado de cuentas de otras comunidades que seguimos localmente.
El asterisco que puse en “cualquiera puede hospedar una comunidad” es porque si hospedar unos archivos en un servidor web ya es una limitante para mucha gente, correr una comunidad de Mastodon es otro nivel. Yo en algún momento había considerado correr mi propia instancia para hospedar mi cuenta y la de mis bots, pero la barrera económica y de tiempo que necesito para mantenerlo me hizo reconsiderar esa opción. Incluso con opciones relativamente económicas para una instancia administrada por una empresa, hay muchas cosas que no entiendo del concepto de “federación” y que no quiero llevarme golpes con mi cuenta principal.
Como en la vida, hay servidores de Mastodon que son como ciudades, y otras que son más bien pueblos pequeños. El servidor donde estoy actualmente, mastodon.social, es el servidor que mantienen los desarrolladores de Mastodon. Dado que es una de las primeras instancias, y dado lo dificil que ha sido separar el concepto de Mastodon, el software, de Mastodon, la comunidad, es un servidor que creció desmesuradamente durante el cambio de gerencia en Tuiter.
Así que hay gente que prefiere servidores más pequeños y más específicos, como un servidor para la gente de infosec, otro para desarrolladores de videojuegos, otro para gente queer trabajando en tecnología, etc., etc. La federación en teoría permite que podamos seguirnos y leernos sin importar en qué servidor estemos. Digo en teoría porque así como uno puede bloquear cuentas que no te gusten, los servidores pueden bloquear a otros servidores, y es ahí cuando el merengue se complica.
Una de las bondades de Twitter es que con la cantidad de gente que atrajo logró integrar una gran cantidad de comunidades: académicos, profesionales, artistas, y demás. Perder Twitter implica que esa Torre de Babel que teníamos de comunidades interconectadas se va a perder. No todo el mundo quiere migrar a Mastodon. Se ha hecho más complicado exportar tu red de contactos de Twitter desde que cerraron el API para las aplicaciones que hacían esto.
De todas maneras, creo que vale la pena prestarle atención a Mastodon en los años venideros. Como alguien que ha creído siempre en la web abierta, estos espacios tienen que ocuparse para ser defendido. De otra manera se pierden. En joinmastodon.org hay una selección grande de comunidades a las que te puedes unir. Espero que te pueda ver por allá.
Había pensado en sacar un álbum este año, pero eso no pasó. La vida pasó. Sin embargo, salieron 35 sketches de canciones este año. Los Tuesday Tunesdays siguen adelante, aunque este año ya se puede notar el impacto del retorno (si así se puede llamar) a la normalidad.
Comencé a usar Chordpro recientemente después de haber estado usando por largo rato Microsoft Word y Chordette para escribir tabs de canciones. Estoy muy contento con los resultados. Sin embargo, aunque la documentación de Chordpro es buena, no tiene un buen tutorial. Tuve que buscar mucho y experimentar para llegar al punto donde estoy contento, y creo que debió ser más simple. Escribí algunas notas sobre cómo llegué a ese punto, con la esperanza de que a otros les pueda ser útil. Actualmente asume que conoces Linux, o que al menos estás familiarizado con las herramientas de línea de comando.
Participé en el pasado Caracas Game Jam 2022 (online) haciendo un videojuego. En esta ocasión decidí utilizar PICO-8, una consola de fantasía (he escrito sobre esto en El Chigüire Literario). Al final del evento presenté Cosmos, un juego para dos jugadores cuyo objetivo es construir un planeta manteniendo varios elementos juntos en el mismo lugar, empleando las fuerzas de atracción y repulsión del sol y la luna. Se puede jugar en el navegador o descargándolo desde esa página.
Escribí código con Lua y utilicé las herramientas internas de PICO-8 para hacer el arte, música y sonido del juego. En PICO-8, todo esto va para el mismo archivo. Para escribir el código utilicé Visual Studio Code con una extensión para subrayar la sintaxis. Así, VSCode ocupa media pantalla, y PICO-8 ocupa la otra mitad. Una vez hechos los cambios en VSCode, paso a PICO-8, presiono CTRL-R y la plataforma lee nuevamente el archivo y agarra los cambios.
Un asunto que tuve constantemente y que supongo se debe a la falta de costumbre: cuando haces cambios en PICO-8, ej. sonido, música, sprites, mapas, tienes que guardar el archivo antes de continuar haciendo cambios en el código con VSCode. Si se te olvida, y haces cambios en Code, cuando haces CTRL-R PICO-8 detecta que hubo cambios en el archivo y en el programa, y se niega a abandonar tus cambios en PICO-8. Esto no es un problema, de hecho es algo bueno. No es crítico al final, porque cuando guardas en PICO-8 automáticamente se muestra el cambio en Code, y puedes hacer Undo, copiar las cosas que habías hecho, Redo, y aplicar los cambios donde sea apropiado. Pero es algo de lo que hay que estar pendiente, es mejor evitar hacer cambios en ambos programas al mismo tiempo.
Creo que el formato de texto plano del archivo lo hace ideal para colaborar, e.g. una persona puede hacer los sprites/mapas, otra hace música/sonido, y se hace merge de todo a través de un repositorio git.
Esto no lo probé porque trabajé solo, pero creo que un setup así es posible.
Los sprites son de 16 colores, y 8x8 en su tamaño mínimo. La paleta de colores por defecto de PICO-8 es muy bonita, y la puedes cambiar si quieres. Lua como lenguaje de programación: ya lo he usado antes y estoy consciente de sus preferencias (ej. arreglos que comienzan por 1 y no por 0, declarar arreglos y tablas, etc.), Lua para PICO-8 tiene unas ligeras diferencias de la implementación standard (ej. las funciones trigonométricas van de 0..1 y no en radianes o grados), pero la documentación oficial es fenomenal, y hay un cheat sheet que también fue extremadamente útil.
La parte de sonido fue mi momento más flojo del proceso, pues era realmente la primera vez que lo utilizaba. Aún así, fue relativamente sencillo hacer la música y entender cómo funciona el sistema. Si hubiese tenido más tiempo hubiese podido escribir el código para que la música cambiase al tempo. La plataforma te ofrece esos datos, pero la llamada de música es super simple y hay que escribir más codigo para este caso.
Me gustaría seguir explorando PICO-8 para otras cosas. Permite hacer llamadas al puerto Serial y al GPIO, lo que lo hace candidato para trabajar con Arduino y Raspberry Pi, me gustaría explorar esa parte un poco más.
English
Español
