Alguien logró ejecutar Doom dentro de una base de datos SQL
Un programador ha logrado ejecutar el clásico videojuego Doom utilizando exclusivamente consultas SQL en una base de datos relacional. El proyecto, denominado SQLDoom, utiliza más de 1.300 líneas de código SQL para generar imágenes en tiempo real con una velocidad de 35 fotogramas por segundo, recreando la experiencia visual del juego original.
El desarrollador, Lukas Vogel, compartió en su blog una explicación detallada sobre cómo logró este avance técnico. Aunque reconoce que usar una base de datos para renderizar un videojuego como Doom puede parecer una idea descabellada, el proyecto demuestra que es posible llevar a cabo tareas complejas usando únicamente lenguaje SQL.
La solución se basa en una combinación entre un cliente en Python que maneja la entrada y salida del juego, controla el tiempo y muestra cada fotograma en pantalla, y una estructura de datos en CedarDB que almacena la geometría del juego y su estado. La lógica del juego se implementa mediante 89 expresiones comunes de tabla (Common Table Expressions o CTE), las cuales son consultadas mediante sentencias SQL para generar los fotogramas.
Esta nueva versión representa una evolución significativa respecto a su anterior proyecto, DoomQL, que en el año pasado buscaba crear un shooter tipo Doom completamente construido con SQL. Ese intento resultó en gráficos en blanco y negro con estilo ASCII, similar a los mapas de Wolfenstein 3D, debido a limitaciones técnicas del enfoque.
En contraste, SQLDoom produce imágenes de 640×480 en color, con una calidad visual que se acerca notablemente a la original. Esto se debe a que los archivos WAD del juego original, utilizados para almacenar sus niveles, están compuestos de elementos como vértices, líneas y sectores, lo cual facilita su conversión a estructuras de datos relacionales.
Una de las ventajas clave del proyecto radica en cómo se manejan las estructuras de partición espacial (binary space partitioning o BSP) del juego. Estas pueden ser representadas en SQL mediante claves de ordenamiento precalculadas durante la carga del nivel. Una simple instrucción ORDER BY permite determinar qué partes de las paredes deben mostrarse en cada fotograma, optimizando considerablemente el rendimiento.
A pesar de estos avances, el proceso no estuvo exento de dificultades. Uno de los mayores desafíos fue implementar la representación de techos y pisos, ya que el método tradicional del juego, basado en planos visuales (visplanes), no se adapta bien a una solución puramente SQL. Para solucionarlo, Vogel recurrió a una solución alternativa poco elegante, que implica iterar sobre una lista ordenada de paneles.
Además, aunque el uso intensivo de lecturas y escrituras en la base de datos podría impactar negativamente el rendimiento, el proyecto logró mantener una velocidad promedio de 60 fotogramas por segundo en una laptop equipada con un procesador Ryzen 7, con picos de caída hasta 35 fps en escenas más complejas.
Una de las ventajas adicionales de esta aproximación es la capacidad de mantener un estado consistente del juego en todo momento, gracias a la naturaleza transaccional de las bases de datos. Esto elimina errores comunes en juegos multijugador, como actualizaciones parciales o inconsistencias en la física del juego, algo que Vogel considera una ventaja importante para servidores online.
Este experimento técnico no solo demuestra la versatilidad de los lenguajes de consulta, sino también cómo se pueden aplicar conceptos modernos de bases de datos a problemas aparentemente no relacionados con la informática tradicional, abriendo nuevas posibilidades para el desarrollo de sistemas distribuidos y concurrentes.
Traducción y adaptación por Tecnología 365.
Fuente original: Ars Technica
