Firebird-DOOM: corren DOOM dentro de SQL en el navegador

Firebird-DOOM: cuando el render de DOOM vive dentro de un SELECT

Un desarrollador logró ejecutar DOOM —el shooter de 1993 de id Software— dentro de una base de datos Firebird SQL compilada a WebAssembly, corriendo enteramente en el navegador. El proyecto, llamado firebird-doom y publicado en GitHub por el usuario mariuz, convierte cada fotograma del juego en una consulta SQL: la lógica del juego son procedimientos PSQL, y la rasterización del escenario vive en vistas y procedimientos almacenados.

Lo que hace único al proyecto frente a otros "DOOM en SQL" no es el concepto, sino la combinación específica: usa la build Electric Firebird (Firebird 6 compilado a WASM) y renderiza los mapas originales de DOOM (mediante el WAD de Freedoom, una reimplementación libre del juego), no una versión simplificada. JavaScript solo se encarga de leer el teclado y pintar los píxeles que Firebird devuelve como filas.

¿Cómo funciona la arquitectura?

El proyecto mapea casi todos los componentes internos del motor original de DOOM a su equivalente en SQL:

• Las lumps del WAD (VERTEXES, LINEDEFS, SIDEDEFS, SECTORS, entre otras) se convierten en tablas con el mismo nombre.
• El bucle de juego se ejecuta como una llamada a doom_tic(tics, fwd, side, turn, fire, use, weapon, run) por cada tic.
• Las tablas de mobjs (info.c en el código original) pasan a ser filas en THING_TYPES.
• El movimiento de monstruos, las puertas, las plataformas y los ascensores están en procedimientos como MONSTERS_THINK, ACTIVATE_LINE y MOVERS_THINK.
• La línea de visión (P_CheckSight) se implementa recorriendo el blockmap celda por celda.
• El ataque por rayo (P_LineAttack) es el procedimiento HITSCAN.

Para la rasterización, el proyecto ofrece dos motores seleccionables desde la interfaz:

• BSP + solidsegs (por defecto): recorre el árbol BSP de adelante hacia atrás, como el R_RenderBSPNode original, descartando subárboles cuyas cajas envolventes ya están ocultas.
• Fuerza bruta: proyecta todos los linedefs visibles sin optimizaciones.

Según el README, en los 36 mapas de Freedoom el renderer BSP es unas 3 veces más rápido que el de fuerza bruta y produce exactamente las mismas paredes visibles, algo que verifica la CI del repositorio.

El truco técnico: simular arrays con strings y CTE recursivos

PSQL no tiene arrays nativos, así que las estructuras internas de DOOM como solidsegs (la lista de columnas de pantalla ya cubiertas) y la pila de recursión del BSP se codifican como VARCHAR con un carácter por columna. El recorrido del BSP termina cuando no queda ningún '0' en el string de cobertura.

El proyecto documenta dos lecciones de rendimiento específicas de Firebird:

• Las tablas derivadas se inlinean. Cada referencia a una columna de un CTE computado reevalúa todo el árbol de expresiones, así que una cadena de cinco proyecciones costaba segundos. La solución: guardar los valores en variables dentro de procedimientos. Un bucle PSQL corre a unos 0,2 µs por sentencia en WASM.
• Fijar el orden del join. Un INNER JOIN entre un rango calculado y SCREEN_COLS tardaba 65 segundos porque el optimizador elegía el lado equivocado. Con CROSS JOIN LATERAL o LEFT JOIN, bajaba a 0,2 segundos.

La familia "DOOM en SQL": CedarDB, DuckDB y ahora Firebird

Firebird-DOOM no es el primer proyecto de este tipo. El README cita tres predecesores:

• SQL DOOM y DOOMQL, de CedarDB: el primero renderiza el WAD original desde la base de datos; el segundo es un juego estilo DOOM escrito en SQL puro.
• DuckDB-DOOM, de Patrick Trainer: un raycaster en SQL dentro del navegador usando DuckDB-WASM.

El proyecto de Trainer fue cubierto por Hackaday en abril de 2025, que destacó que el estado del mundo se modela completamente en la base de datos y que el render se hace con vistas SQL que hacen raytracing; el rol de JavaScript se reduce a unir las consultas y manejar el input.

La diferencia de firebird-DOOM frente a esos antecedentes, según el propio README, es que es gráfico (no ASCII), juega los mapas reales de DOOM (gracias a Freedoom) y corre Firebird dentro de la pestaña, sin servidor.

¿Qué significa esto para tu startup?

El proyecto no es un producto comercial —el repositorio mostraba 0 estrellas, 0 watchers y 0 forks al momento de la publicación— pero demuestra tres cosas relevantes para founders que construyen sobre datos y WebAssembly:

1. WebAssembly ya permite mover cargas serias al navegador. Que un motor de base de datos completo con procedimientos almacenados, recursión y consultas complejas corra dentro de una pestaña con WASM abre la puerta a productos que antes requerían backend dedicado: demos interactivas, herramientas internas, MVPs de data apps. Firebird-DOOM usa SharedArrayBuffer y pthreads; el service worker es lo que aísla el origen para habilitar esas APIs.
2. SQL puede ser un motor de lógica de negocio, no solo de consultas. Si tu startup modela reglas, simulaciones o pipelines de datos en SQL, este proyecto es un recordatorio de que las bases de datos modernas pueden ejecutar lógica compleja procedural —CTE recursivos, window functions, procedimientos— con buen rendimiento. Firebird 6, según el README, ejecuta bucles PSQL a 0,2 µs por sentencia.
3. El rendimiento extremo requiere entender al optimizador. Las dos "lecciones de rendimiento" del README (tablas derivadas inlineadas, orden de join) son problemas reales que cualquier equipo que trabaje con SQL complejo va a encontrar. La diferencia entre 65 segundos y 0,2 segundos en una consulta no la marcó el hardware, sino saber qué le duele al optimizador.

Fuentes

• firebird-doom (GitHub) (fuente original)
• Abusing DuckDB-WASM To Create Doom In SQL — Hackaday