Peter Gostev construyó DOOMQL usando GPT-5.6 Sol: un pequeño juego tipo Doom donde SQLite es el motor gráfico, no el lugar donde guardar datos. Movimiento, colisiones, enemigos, combate y cada píxel RGB viven dentro de queries SQL, incluyendo un ray tracer completo implementado como CTE recursiva.

La base de datos se puede inspeccionar con Datasette: una demo pública muestra una app HTML+JavaScript que lee la vista frame_pixels en tiempo real mientras el juego corre en la terminal, con un minimapa añadido con Claude Fable 5 en pocos minutos.

Por qué te importa. No es una herramienta lista para usar, es un caso de estudio sobre qué pasa cuando le das a un modelo un objetivo técnico preciso y el espacio para trabajar. El código es público en GitHub, se clona y ejecuta en cinco minutos (uv run host/doomql.py). No se trata de viabilidad — SQL no está diseñado para renderizar frames — sino del proceso: un problema irreal descompuesto en pasos ejecutables, con el modelo escribiendo código que realmente funciona.

Si experimentas con agentes de coding, este es el tipo de experimento que muestra los límites prácticos: dónde el modelo resuelve bien, dónde necesitas verificar, y hasta qué punto puedes llegar antes de que el output sea demasiado frágil.

En detalle

El contexto. Los modelos frontier como GPT-5.6 Sol, Claude Fable 5 y Muse Spark 1.1 han cambiado la escala de proyectos que puedes confiar a un asistente de coding: de “escribe esta función” a “construye este sistema”. DOOMQL es un experimento en el límite de esa capacidad: un sistema completo donde el modelo tuvo que entender cómo representar gráficos 3D, física básica y lógica de juego dentro de un motor no diseñado para ninguna de esas cosas.

Cómo funciona. El juego es un script Python para terminal que crea una base de datos SQLite. Cada frame es una query: una CTE recursiva implementa el ray casting (proyección de rayos desde el punto de vista del jugador), calcula distancias a las paredes, determina la altura de las columnas en pantalla y genera valores RGB para cada píxel. El resultado termina en una vista frame_pixels(x, y, r, g, b) que puedes consultar o visualizar.

La base de datos se inspecciona con Datasette y el plugin datasette-apps, que permite crear interfaces HTML+JavaScript dentro de Datasette mismo. En la demo, un prompt a Claude (“construye una app que muestre el estado de pantalla desde la vista frame_pixels, actualiza cada segundo”) produjo en una iteración un visualizador funcionando. El minimapa llegó con “añade un minimapa”, sin necesidad de reescribir la app.

Qué dice realmente. El experimento no demuestra que SQL sea un buen motor gráfico — no lo es. Demuestra que un modelo fuerte puede traducir un problema absurdo en código ejecutable, si le das:

1. Un objetivo técnico preciso (“SQL como motor gráfico”).
2. Un lenguaje con semántica rigurosa (SQL, donde una query correcta siempre hace lo mismo).
3. Un espacio de trabajo aislado para probar y corregir (la base de datos local).

El código producido es legible y público: puedes seguir la lógica del ray tracer dentro de la CTE, ver cómo representa el estado del juego y dónde el modelo hizo decisiones de diseño (por ejemplo, cómo gestiona las colisiones con queries recursivas en lugar de un bucle imperativo).

Los límites. No sabemos cuántos intentos tomó llegar a una versión funcional, ni cuánta supervisión humana fue necesaria para corregir errores lógicos o de rendimiento. Un proyecto así requiere muchas rondas de verificación: SQL es preciso pero no perdona, y un bug en una CTE recursiva es difícil de aislar incluso para un humano. El repo no documenta el proceso de desarrollo, solo el resultado final.

Además, el experimento es intencionalmente pequeño: un nivel, enemigos básicos, sin IA adversaria compleja. Añadir complejidad (más niveles, interacciones más ricas) podría llevar el sistema más allá del límite de lo que SQL puede manejar con rendimiento aceptable.

Qué hacer con esto. Si trabajas con agentes de coding, este caso es útil por dos razones:

1. Te muestra dónde buscar cuando evalúas un output. El código de DOOMQL es verificable: puedes ejecutarlo, inspeccionar la base de datos, leer las queries. Un asistente que produce código en esta escala debe generar artifacts que puedas ejecutar y comprender, no solo copiar y pegar.
2. Te da un ejemplo de problema irreal resuelto bien. Construir un juego en SQL es un problema con restricciones fuertes y una solución no trivial. Si pruebas un modelo en tareas no estándar, elige problemas con esta estructura: objetivo claro, verificación inmediata (funciona o no), y complejidad suficiente para revelar límites.

Para probarlo, clona el repo y sigue el README: cinco minutos para tener el juego corriendo, otros cinco para abrir la base de datos en Datasette y ver qué hay dentro. No es una herramienta que usarás en producción, pero es un buen ejemplo de qué puedes pedirle a un modelo cuando sabes qué verificar.