Los que me conocéis ya sabéis que la demoscene es una de esas espinitas que llevo clavadas desde hace décadas. En 1998 se me fue el melón y organicé la RadyKal Party en Granada, una party amiguera a la que vinieron más de 300 personas. Aquello fue una locura maravillosa que me dejó marcado para siempre. Pues bien, veintiséis años después sigo dándole vueltas al tema, solo que ahora con algo más de experiencia y bastantes más canas.
Todo empezó en la Posadas Party de 2022. Necesitábamos un sistema de votaciones y, como suele pasar en estos casos, acabé mirando lo que había disponible. El estándar de facto en la demoscene es wuhu, un sistema de gestión de parties escrito en PHP que lleva años funcionando en medio mundo y que ha sido fundamental para la escena. Un proyecto con mucho mérito y muchas horas de trabajo detrás. Pero yo tenía en la cabeza una visión algo diferente: quería explorar cómo sería un sistema así construido desde cero con las herramientas y los enfoques que usamos hoy en día, y con algunas ideas propias que me rondaban desde hacía tiempo.
Así que hice lo que cualquier desarrollador sensato haría en mi situación: en lugar de contribuir al proyecto existente, me lié la manta a la cabeza y decidí escribir uno desde cero. Sí, lo sé, el clásico síndrome del «not invented here». Pero es que tenía ganas, y cuando uno tiene ganas de programar no hay quien lo pare ;-)
¿Qué es DPMS?
DPMS (Demo Party Management System) es un sistema web para gestionar todos los aspectos de una demo party: el registro de usuarios, la gestión de competiciones (compos), la subida de producciones, el sistema de votaciones y, lo que considero la joya de la corona, un sistema de presentación en pantalla llamado StageRunner. Todo ello empaquetado con Docker para que desplegarlo sea coser y cantar.
La pila tecnológica
Para el backend me decanté por Django con Django REST Framework. Sí, ya sé que en su día aposté por web2py y me llevé algún que otro disgusto, así que esta vez fui a lo seguro. Django es un tanque: robusto, bien documentado y con una comunidad enorme. La base de datos es PostgreSQL, porque las cosas hay que hacerlas bien.
El frontend es un SPA hecho con React y Material-UI. Aquí tengo que confesar que React no es mi framework favorito del mundo mundial, pero hay que reconocer que para aplicaciones de este tipo funciona de maravilla. Le he metido Three.js para los fondos animados en WebGL (un Hyperspace, unas ondas, una rejilla de energía y otra estilo TRON), porque si estás haciendo software para la demoscene y no tiene efectos gráficos molones es que algo estás haciendo mal ;-D
Para la landing page pública tomé una decisión algo peculiar: en vez de hacerla con React, la hice con templates de Django renderizados en servidor. ¿Por qué? SEO. Así de simple. Los buscadores necesitan poder indexar la información del evento sin tener que ejecutar JavaScript, y esta solución es mucho más pragmática que meterse en el berenjenal de Next.js o similar para una simple página de aterrizaje.
StageRunner: la presentación en pantalla reinventada
Si hay algo de lo que estoy especialmente orgulloso es de StageRunner. En las parties, cuando se proyectan las producciones y los resultados en la pantalla grande, tradicionalmente se usa un sistema que se configura editando ficheros. StageRunner es otra historia: tiene un editor visual de tipo drag-and-drop donde diseñas las diapositivas arrastrando elementos (texto, imágenes, vídeos, relojes de cuenta atrás, información de producciones, barras de patrocinadores…) sobre un canvas con proporción 16:9. Todo con transiciones configurables, rotación, z-index y coordenadas en porcentaje para que escale a cualquier resolución.
Luego, el visualizador se ejecuta a pantalla completa en el proyector del evento y se controla remotamente a través de la API REST. Nada de tocar ficheros, nada de reiniciar procesos. Cambias algo en el editor y se refleja en tiempo real. Así debería haber sido desde el principio.
Seguridad, esa gran olvidada
Una cosa que me molestaba de muchos proyectos similares es que la seguridad se trata como algo secundario. En DPMS me lo he tomado en serio: Argon2 para el hashing de contraseñas (el ganador de la Password Hashing Competition, nada menos), tokens JWT para la autenticación, y en producción el stack incluye Nginx con ModSecurity y las reglas OWASP CRS como WAF. Igual es pasarse un poco para un proyecto de la demoscene, pero después de tantos años administrando servidores uno tiene sus manías ;-)
También he dejado preparada la integración con SceneID, el sistema de autenticación unificado de la demoscene, aunque de momento está comentada esperando a que la active cuando toque.
El código es libre, por supuesto
DPMS está publicado en GitHub bajo licencia MIT: https://github.com/FreeMEM/DPMS. Si organizas parties o te interesa el proyecto, eres bienvenido a echarle un ojo, probarlo, y contribuir. O simplemente a criticar mi código, que también se aprende mucho de eso.
El plan es seguir desarrollándolo con calma. Tengo un roadmap de 9 fases que sobre el papel suena muy bonito, pero ya sabemos cómo van estas cosas: la vida real siempre tiene otros planes. De momento, la primera prueba de fuego real será en la Posadas Party 2026 este junio, donde DPMS se encargará de gestionar todo el evento. Si sobrevive a eso, podré decir que funciona de verdad.
Trataré de ir contando los progresos por aquí. Y si alguien se anima a probarlo en su propia party, que me escriba, que me hace ilusión :-)
Ah, y por cierto: sí, he usado Claude como copiloto de desarrollo durante todo el proyecto. El fichero CLAUDE.md del repositorio lo delata. Pero eso da para otro post entero ;-P