El nuevo hogar de Doom es una base de datos
Doom acaba de encontrar un nuevo hogar: una base de datos. SQLDoom, un proyecto de Lukas Vogel en CedarDB, no es simplemente un juego que almacena puntuaciones altas en una base de datos o una imitación visual. Es una reimplementación completa del Doom original de 1993, con su lógica de juego central y renderizado de gráficos ejecutándose completamente en SQL.
Esta arquitectura está elegantemente desacoplada. La lógica del juego y el motor de renderizado se ejecutan como consultas SQL, mientras que Python actúa como un puente ligero. El papel de Python se limita a capturar la entrada del teclado, gestionar el tiempo del bucle del juego y mostrar el búfer de fotogramas resultante. Cada fotograma que ves es el resultado de una única y masiva consulta SQL.
La escala de este emprendimiento es impresionante. La resolución de 320x200 del juego, que totaliza 64,000 píxeles, es calculada por el renderizador, que comprende aproximadamente 1,300 líneas de SQL a través de unos 89 Common Table Expressions (CTEs). La lógica del juego añade otras 5,900 líneas de SQL. Toda esta base de código SQL es notablemente más corta que las aproximadamente 9,000 líneas de lógica de juego en C del Doom original.
Una consulta pinta 64,000 píxeles
Cada fotograma renderizado en SQLDoom se origina a partir de una única y compleja consulta de base de datos. Esta consulta calcula el color para cada uno de los 64,000 píxeles (resolución de 320 × 200) en pantalla, devolviendo la imagen como datos de mapa de bits sin procesar, con una fila representando cada píxel. La consulta de renderizado por sí sola abarca aproximadamente 1,300 líneas de SQL, utilizando unos 89 Common Table Expressions (CTEs).
Las operaciones relacionales difieren fundamentalmente del código procedimental tradicional. En lugar de bucles explícitos que iteran a través de objetos del juego, SQLDoom aprovecha las operaciones basadas en conjuntos para procesar entidades colectivamente. Esto permite que una única sentencia UPDATE, por ejemplo, modifique los estados de todos los monstruos simultáneamente, un marcado contraste con los numerosos bucles for o while de la implementación original en C.
Las métricas de rendimiento son impresionantes para un juego nativo de base de datos. La lógica central del juego se adhiere a los 35 tics por segundo originales de Doom, asegurando un ritmo de juego auténtico. Sin embargo, el renderizador puede alcanzar hasta 60 fotogramas por segundo (FPS) en hardware moderno mediante la interpolación de posiciones de cámara entre estos tics de juego, proporcionando una experiencia visual más fluida que el original de 1993. Lukas Vogel en CedarDB ha demostrado eficazmente la sorprendente capacidad de SQL como motor de juego.
La base de datos hace el trabajo pesado
Renderizar Doom en una base de datos presenta una compensación fascinante. El motor original de 1993, diseñado por John Carmack, conservaba magistralmente los ciclos de CPU con árboles de Binary Space Partitioning (BSP) para determinar la visibilidad. SQLDoom, por el contrario, calcula por fuerza bruta la profundidad y la oclusión en sus 64,000 píxeles por fotograma. Esto hace que la visibilidad sea la parte más lenta de la tubería de renderizado SQL.
Este enfoque de fuerza bruta solo es viable gracias a la arquitectura de CedarDB. Su motor de consultas compila consultas SQL directamente a LLVM IR y luego a código de máquina nativo, permitiendo que cargas de trabajo analíticas complejas se ejecuten con una velocidad impresionante: hasta 60 fotogramas por segundo en una computadora portátil. Esta compilación es crucial para manejar las 1,300 líneas de SQL en una sola consulta de renderizado, como se describe en la entrada del blog del proyecto: We Ported the Original Doom to SQL - CedarDB.
El mundo del juego en sí se transforma en datos estructurados. Los icónicos activos WAD de Doom, que definen todo, desde la geometría del mapa hasta las texturas, encuentran nuevos hogares como tablas relacionales. Esto incluye:
- Mapas
- Sectores
- Linedefs
- Texturas
Incluso elementos individuales como la escopeta se convierten en filas de una tabla, lo que permite la manipulación directa mediante SQL para cambiar las mecánicas del juego, como actualizar un arma para que dispare 500 perdigones con una simple sentencia UPDATE. Esto hace que todo el mundo del juego sea consultable y modificable a través de operaciones de base de datos estándar.
¿Te está gustando? Recibe uno así en tu bandeja cada mañana.
un correo al día · date de baja en dos clics · sin rastreadores de terceros
Cuando las mecánicas de juego se convierten en filas editables
Un diseño inusual también produce resultados sorprendentes. Debido a que las armas y las estadísticas del jugador residen como datos de tabla, una sola actualización SQL puede alterar el número de perdigones de una escopeta o la salud base de un jugador. Esto demuestra las capacidades dinámicas de la base de datos, aunque una partida en vivo restringiría tal manipulación directa.
La funcionalidad multijugador surge de forma natural a partir de las transacciones de la base de datos. Cada tick del juego se procesa como una transacción aislada, asegurando que todos los jugadores consulten una vista consistente y sincronizada del mundo del juego. Las funciones restringidas evitan que los clientes alteren directamente valores protegidos, como su propia salud, manteniendo la integridad del juego.
SQLDoom trasciende la mera novedad, sirviendo como un banco de pruebas riguroso para motores de consulta de bases de datos como plataformas de computación. Este proyecto se basa en el prototipo anterior de raycasting ASCII de Lukas Vogel, DOOMQL, superando los límites de lo que las bases de datos relacionales pueden lograr. SQLDoom nos invita a reconsiderar cómo otras mecánicas de juego complejas podrían representarse y ejecutarse como datos y consultas puras.
Preguntas frecuentes
¿Qué es SQLDoom?
SQLDoom es un proyecto de Lukas Vogel en CedarDB que reimplementa la lógica de juego y el renderizado de gráficos de Doom en SQL.
¿SQLDoom se ejecuta completamente en SQL?
La lógica del juego y el renderizador se ejecutan en SQL. Python maneja la entrada del teclado, la sincronización y la visualización del frame renderizado.
¿Cuántos píxeles renderiza SQLDoom por frame?
Calcula 64,000 píxeles por frame, igualando la resolución de 320 por 200 de Doom.
¿Cómo maneja SQLDoom el multijugador?
Los ticks del juego se ejecutan como transacciones de base de datos, brindando a los jugadores una vista sincronizada del estado compartido del juego.