Lukas Vogel ha portado el juego original Doom de 1993 para que se ejecute completamente dentro de una base de datos SQL, con la lógica del juego y el renderizado implementados como consultas SQL. Según la entrada del blog de Vogel, el proyecto ejecuta el episodio shareware auténtico de Doom utilizando CedarDB, donde SQL maneja todo el procesamiento del juego mientras un cliente Python mínimo gestiona únicamente el timing de entrada, la lectura del teclado y la salida de visualización. La implementación incluye soporte multijugador, con Vogel señalando que 'Multiplayer también funciona' y demostrando servidores en la UE y EE. UU. donde los jugadores pueden unirse a partidas de deathmatch. El sistema separa claramente las responsabilidades: el cliente Python impulsa el juego a 35 ticks por segundo, lee la entrada del teclado y muestra el bitmap resultante, mientras que toda la evolución del estado del juego y el renderizado ocurren dentro de la base de datos. El formato de archivo WAD de Doom, que Vogel describe como 'altamente relacional', se tradujo a tablas de base de datos utilizando aproximadamente 1,000 líneas de código Python, con la importación de los datos completos de Doom 1 tomando alrededor de 18 segundos en su portátil. La lógica del juego se ejecuta como un bucle fijo de 35 Hz utilizando el lenguaje cedarscript de CedarDB, que se asemeja a PL/pgSQL. Cada tick procesa la entrada del jugador, la IA de enemigos, la recogida de objetos, el movimiento de proyectiles, explosiones, renderizado de sprites, animaciones, balanceo de la vista y actualizaciones del HUD. Las mediciones de rendimiento muestran que el tick más exigente (en el nivel E4M1 con 46 monstruos despiertos) tarda 10,45 milisegundos — aproximadamente el 37% del presupuesto disponible de 28,6 milisegundos por tick — mientras que los ticks típicos con menos monstruos promedian apenas 2,15 milisegundos o el 8% del presupuesto. A pesar de la inicial complejidad, la implementación en SQL resulta sorprendentemente compacta. La lógica del juego comprende aproximadamente 5,900 líneas de SQL, que Vogel señala que es 'definitivamente menos que el código fuente original en C que hace lo mismo en alrededor de 9,000 líneas.' El pipeline de renderizado utiliza alrededor de 1,300 líneas de SQL a través de 89 Expresiones de Tabla Común (CTE) por cuadro, aproximadamente 2,5 veces menos líneas que el motor de renderizado de Linux Doom de 3,300 líneas. Vogel informa que expresar la lógica del juego como sentencias SQL UPDATE con cláusulas WHERE finalmente hizo que el patrón Entity Component System (ECS) le 'hiciera clic', ya que cada operación SQL procesa naturalmente todas las entidades coincidentes en paralelo. Este esfuerzo se basa en el proyecto anterior DOOMQL de Vogel, que implementó un juego tipo Doom en SQL pero utilizó raycasting (similar a Wolfenstein 3D) en lugar del renderizado basado en el árbol BSP real de Doom. DOOMQL presenta una arquitectura capaz de multijugador donde CedarDB maneja la sincronización de jugadores y el estado, con un cliente Python mínimo de 150 líneas para entrada/salida. Juntos, estos proyectos demuestran la viabilidad de SQL para aplicaciones interactivas complejas, aunque Vogel reconoce preguntas sobre si dicho enfoque representa una buena práctica de ingeniería.
Esta imagen muestra las 89 Expresiones de Tabla Común (CTE) ejecutadas por cuadro, como se menciona en la descripción del artículo sobre el pipeline de renderizado de SQL Doom que utiliza alrededor de 1,300 líneas de SQL en 89 CTEs.
Esta visualización respalda el análisis de rendimiento del artículo, donde el tick más exigente tarda 10,45 ms (37% del presupuesto de cuadro) y los ticks típicos promedian 2,15 ms (8% del presupuesto), medido en la portátil del autor.
Esta imagen confirma que el puerto de Doom basado en SQL representa correctamente los gráficos originales de Doom, tal como se indica en la introducción del artículo sobre el proyecto que ejecuta el episodio shareware auténtico de Doom.