Doom corriendo en SQL: broma o genialidad absoluta

Alguien Gtz quedó sin palabras y escribió un post en lugar de hablar. Suena a broma, pero literal: el ingeniero de bases de datos Gtz Rehfeld publicó SQLDoom, una reescritura completa del Doom original de 1993 que corre entera dentro de una base de datos SQL. No es un emulador. No es un vídeo. No es arte ASCII. La lógica del juego, los colisiones, la IA de los monstruos, el renderizado 3D, el deathmatch multijugador y hasta el framebuffer de 320x200 salen de consultas SQL.

Suena a shitpost de viernes por la tarde. Es lo contrario: un ejercicio de ingeniería con reglas autoimpuestas tan estrictas quetermina siendo casi Zen.

Las cinco reglas que hicieron imposible el proyecto (y por eso funcionó)

El autor puso cinco condiciones antes de escribir una línea. La que rompe el cerebro es la segunda:

1. Debe parecer al Doom real. No "algo similar a Doom". Doom.
2. El renderizado debe ser 100% SQL. La única salida aceptable: una tabla o un bitmap con los valores RGB exactos de cada píxel.
3. El game loop también debe ser 100% SQL. Se permiten funciones definidas por el usuario dentro de la base.
4. El cliente puede estar en otro lenguaje, siempre que solo lea el teclado, mida el tiempo y muetre el bitmap que le devuelve la base.
5. Python debe aburrirse. Suena a broma, pero es la regla más importante.

El cliente real son unas 400 líneas de Python. No calcula nada de física ni de render. Solo empuja teclas y pega el framebuffer en la pantalla.

5.900 líneas de SQL que le ganan al C original

El dato que hiela la sangre: la lógica de juego completa son ~5.900 líneas de SQL. El Doom original en C lo hacía en aproximadamente 9.000 líneas.

Sí, la versión SQL es más corta que el código en C de los años 90. Y funciona.

La importación del WAD completo tardó unos 18 segundos en su portátil. Pero una vez cargado, corre a 35 FPS exactos — el reloj original — con renderizado desacoplado a 60 Hz. El deathmatch de cuatro jugadores funciona de verdad.

El tic de juego más lento que pudo encontrar fue en E4M1 con 46 monstruos despertados cargando a través de una puerta abriéndose: 10,45 milisegundos, o sea el 37% del presupuesto disponible por tic. Un tic normal con 6 monstruos: 2,15 ms, cerca del 8%.

Traducido: en los peores momentos documentados, le queda casi dos tercios del tic libre. Este hombre hizo Doom en SQL y le sobró CPU.

La trampa de pensar en Doom: SQL no tiene bucles ni estado mutable

El render de Doom es deliberadamente imperativo:

El coste oculto: la base de datos es el motor gráfico

El punto que casi nadie menciona: el renderer completo es una vista materializada de ~1.300 líneas de SQL repartidas en 89 CTEs. Cada frame es una vista gigante que lee la geometría del nivel, el estado del juego y la posición del jugador, y devuelve el framebuffer completo.

Y aquí está la ironía que este proyecto no resuelve: la salida es una tabla de píxeles. Eso significa que cada frame tiene que serializarse, viajar por el socket y ser deserializada para llegar a la pantalla. CeroVQ. El pipe entre base de datos y pantalla es ahora el cuello de botella, no la CPU.

Es el tipo de detalle que separa un toy fizz de una arquitectura real. Y es también la razón por la que nadie va a reemplazar Unity con esto.

El BSP tree aplastado en 40 bits

La optimización más elegante: en carga, precomputa todos los caminos raíz→subsector del árbol BSP, los empaqueta en un bigint de 40 bits y los ordena lexicográficamente. Así el orden de dibujado (de frente hacia atrás, para poder descartar lo ocluido) sale de un simple sort.

40 bits alcanzan porque el BSP más profundo del juego —E4M8— tiene 32 niveles. Cualquier mapa hasta 256 veces más grande que el vanilla entra en el mismo número.

La ibbzación de oclusión también sale del mismo siteo: cada nodo tiene la bounding box de sus hijos, y si la cámara está completamente fuera, esa rama entera se descarta. Culling gratis.

El veredicto: es un stunt genial y también una advertencia

Mi opinión sin filtro: SQLDoom es probablemente el proyecto de programación más absurdo yähr elegante del año. Y al mismo tiempo es la demostración perfecta de que "se puede hacer en SQL" no significa "conviene hacerlo en SQL".

Las funciones de ventana substituting bucles, las CTE massivas imitando un BSP, la materialización de cada frame como una vista: todo funciona, todo es elegante, y todo es exactamente la señal de que elegiste la herramienta equivocada para el trabajo.

Pero eso también lo hace perfecto para aprender. Cualquiera que haya abierto una SELECT con miedo desde algún CRUD de la facultad acaba de descubrir que su base de datos puede renderizar un frame de Doom. Eso es la mejor propaganda técnica que he visto en años.

Haz NOTA FINAL: SQLDoom fue escrito durante la baja por худож parental del autor. Es decir, no fue un fin de semana heroico. Fue

👇 Comenta: ¿tú serías capaz de escribir un clon de Bubble Shooter en SQL puro, o ahí sí se acaba la perished?

Comparte esto con alguien que sigue diciendo que SQL es solo para tablas. Y con ese compañero de trabajo que aún pone lógica de negocio en el backend "porque siempre se ha hecho así".